Re: writepage return value check in vmscan.c

[Andrew Morton]

[e-mail] wrote:
> 
> On Fri, Oct 25, 2002 at 11:44:14AM -0700, Andrew Morton wrote:
> > [e-mail] wrote:
> > >
> > > bigmm -i 3 -t 2 -c 1024
> >
> > That's a nice little box killer you have there.
> 
> Thanks. It kills on all our customer's kernel, they don't use the
> bleeding edge kernel at all. It is interesting to see vmware
> serve as some heavy load stress test tool. It will give some real
> world load to the OS, e.g. the load need to boot a windows etc. You
> can stack many of them to abuse the OS.

I tested Andrea's latest kernel.  It survived.

Probably because it left 100 megabytes of lowmem unallocated
throughout the test.

> >
> > With mem=4G, running bigmm -i 5 -t 2 -c 1024:
> >
> > 2.4.19: Ran for a few minutes, got slower and slower and
> > eventually stopped.  kupdate had taken 30 seconds CPU and
> > all CPUs were spinning in shrink_cache().  Had to reset.
> >
> > 2.4.20-pre8-ac1: Ran for a minute, froze up for a couple of
> > minutes then recovered and remained comfortable.
> 
> How many instance of bigmm left there? It should be 10 bigmm
> processes before oom kickin.

Well, they should all be left running?  All this memory has
file-backing, and is easily reclaimable.

umm, yes.  There could be bogus oom-killings in the combined-LRU
VMs.  But I saw none in testing.

All of which is great fun, but it leaves open the question "what
the heck can vmware do about it". I wish there was a clear answer.

If the customer is running a suse/UL kernel they're presumably OK.

If their kernel comes from kernel.org they should add Andrea's patch.
Which means they get an absolute boatload of stuff which they may
not want:
 1223 files changed, 306053 insertions(+), 9655 deletions(-)
but that kernel performs well.

If they're running an RH-rmap kernel then they're probably okayish,
although I'd recommend more testing there.

If they're running an RHAS-style kernel then I do not know.  It may
fail.