Re: writepage return value check in vmscan.c

[Andrea Arcangeli <andrea@suse.de>]

On Mon, Oct 28, 2002 at 11:53:28AM -0800, Andrew Morton wrote:
> chrisl@vmware.com wrote:
> > 
> > On Fri, Oct 25, 2002 at 11:44:14AM -0700, Andrew Morton wrote:
> > > chrisl@vmware.com 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.

that's unrelated to the vm code though (in terms of per-zone lru
mentioned by Andrew for 2.5 that in turns breaks all the aging
information compared to 2.4), that is meant to definitely fix another
highmem unbalance bug where all the lowmem could be pinned and made
unfreeable by lowmem users despite plenty of highmem is still available.
That's the fix to the google mlock deadlock, mainline has a weak attempt
to fix it in another manner, but I backed it out since it's too weak to
be effective in the real workloads (it didn't fix the problem in real
life) and I instead kept my first approch that is THE definitive fix.
btw, 2.5 has still the weak approch, so it's still subject to the google
bug, I will fix it in my tree while moving to 2.5.

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

Right.

Andrea

(PS about your previous comment on the swap needed: kernels <= 2.4.9
 (9 != 19) also have the problem that vm+swap isn't all the vm that vmware
 can use, for them you need the double of swap)