Michael Anderson wrote:
>
> I have a performance problem on a HP3000/928. [...]

> Using SOS from LUND I found the culprit that was using 80-95 percent of the
> CPU. This process was not releasing the CPU at all, as far as I could tell.
> SOS was unable to tell me what program was doing this. I knew it was a
> program located down some hierarchical POSIX path, but SOS blamed it all on
> SH.HPBIN.SYS.

OK, Posix enters the picture...

> Why can't SOS Identify the program that is doing this?
> Is the reason SOS can't find this Process name because SH.HPBIN.SYS is
> probably using the "fork" system call instead of the "CREATEPROCESS"
> intrinsic?

Most likely.  The concept of "fork()" is about as alien to the MPE design
as you can possibly get.  Consequently it's implementation took quite
some doing - I don't think 4.5 completely supported it (if at all, I
skipped that release), 5.0 had most of it, 5.5 tried to optimize it,
but the fact remains it's the Achille's heel of Posix on MPE.

I have no idea how it is actually implemented other than it appears to
bypass the traditional createprocess() mechanism.  The parent's data
area has to be "cloned" and process-specific mechanisms adjusted for the
new child process.  Fork seems to (I could well be wrong; I'd *love* to
hear a lab explanation of the real details) bypass the loader.  As a
result, the process creation overhead normally absorbed by the loader
is inherited by the parent (again, speculation).

> Also, I have noticed when I use the shell (SH.HPBIN.SYS) to do a simple
> command like: "tail -f /usr/local/samba/var/log.nmb" It begins to use 80-90
> percent CPU. I think something is seriously wrong here.

I believe the "posix path" here is to fork() sh.hpbin.sys and the child
process then does an execv() of tail.hpbin.sys.  You're looking at two
"unnatural" MPE process creations for one simple command.  Someone
*PLEASE* explain what's really happening here, I'm outta my league.
The execv() can't very well act like it's Unix counterpart; more likely
it creates yet another MPE child (?).  Furthermore, if any of the
invoked commands (like tail) use system(), we may have yet another
fork()/invocation of sh.hpbin.sys/fork()/execv() the command.

Starts to add up, doesn't it?

To make matters worse, posix code is linked with static RLs so an awful
lot of code is being carried around and memory wasted.  One of the posix
smoothing issues was to relink the shell and utilities with a more
traditional XL to make this code shared.  The results could go either
way -- would increase load time, but decrease the memory requirements
of the process.  There are no solid benchmarks on this yet.

Bear in mind that much of the posix shell and utilities were taken
literally from MKS, not CSY.  They certainly didn't take any exotic
steps to optimize things for MPE.  Instead, we have the somewhat kludgy
fork()/exec() interfaces.  Function took precedence over performance
by an unheralded margin.

Jeff Kell <[log in to unmask]>