Re: Linux 2.4.10-pre11

[Andrea Arcangeli <andrea@suse.de>]

On Mon, Sep 17, 2001 at 10:48:34PM -0700, Andrew Morton wrote:
> Linus Torvalds wrote:
> > 
> > Ok, the big thing here is continued merging, this time with Andrea.
> > 
> 
> In one test here the VM changes seem fragile, and slower.
> 
> Dual x86, 512 megs RAM, 512 megs swap.  No highmem.
> 
> The workload is:
> 
> 	while true
> 	do
> 		/usr/src/ext3/tools/usemem 300
> 	done
> 
> 	(This just mallocs 300 megs, touches it then exits)
> 
> in parallel with
> 
> 	time /usr/src/ext3/tools/bash-shared-mapping -n 5 -t 3 foo 300000000
> 
> on ext2.
> 
> (bash-shared-mapping is a tool which I wrote for ext3.  It's one of the
>  most aggressive VM/MM stress testers around, and has found a number of
>  kernel bugs).
> 
> On 2.4.9-ac10, the b-s-m run took 294 seconds.  On 2.4.10-pre11 it
> took 330 seconds DESPITE the fact that one of the b-s-m instances
> was oom-killed quite early in the test.
> 
> `vmstat' took about thirty seconds to start (this is usual), but
> was promptly killed, despite having (presumably) a small RSS.  Instances
> of `usemem' were oom-killed quite frequently.  In 2.4.9-ac10, nothing
> was oom-killed.

should be the very same problem identified by Marcelo. I'm wondering why
I didn't reproduced here during testing, 512mbytes is not highmem and my
desktop has 512mbytes too and it didn't killed anything yet. As for the
slowdown there are a few localized places to look at. but let's fix the
oom first.

> Andrea, it would be most useful if you were to spend some time (say, four hours)
> commenting the code and telling us how it works.

I will do that and I'll answer to any question ASAP, no panic. We may
even want to change part of the core logic over time if it doesn't
perform wonderfully. But first prio at the moment is to fix the oom you
also noticed (the "hiding" logic mentioned by Marcelo), the rest of the
changes should be a very solid base for a very solid and fast 2.4 vm.

Andrea