On 3 Aug 1997, Greg Stark wrote:
>
> It sounds like the problem at least in the xboard case was memory starvation,
> not cpu load. The CPU is not the only scarce resource in a computer, memory
> and io bandwidth are both likely to cause a machine to become unresponsive, in
> many cases long before cpu load becomes a problem. The load average number is
> handy but not really a precise measurement of how unusuable the machine is.
>
> You can avoid the vfork error by increasing your swap space, but the machine
> will still become unresponsive because it will take a long time swapping in
> and out xboard processes between handling your keyboard io. I think the
> scheduler inhereits the BSD approach of prefering interactive processes but
> that only goes so far.
>
> greg
>
The machine has 80M Ram and 256M of swap. Vfork quit at exactly the point I
ran out of real mem and started swapping.. which the third copy of xboard
instigated. At the point of uselessness, only 25M of swap was being used.
As to mem bandwidth, I have enough that I can whip an SGI-R4400-150 running
a humongous distributed simulation I was tinkering with a while back.. so
I don't think that's the problem. It appeared to be spending all of it's
time paging.. what I called no-blink swapping.
-Mike