Re: 1352 NUL bytes at the end of a page? (was Re: Assertion `s && s->tree' failed: The saga continues.)

[Andrea Arcangeli <andrea@suse.de>]

On Sat, May 15, 2004 at 09:52:50PM -0700, Linus Torvalds wrote:
> 
> 
> On Sat, 15 May 2004, Steven Cole wrote:
> > 
> > OK, will do.  I ran the bk exerciser script for over an hour with 2.6.6-current
> > and no CONFIG_PREEMPT and no errors.  The script only reported one
> > iteration finished, while I got it to do 36 iterations over several hours earlier
> > today (with a 2.6.3-4mdk vendor kernel)
> 
> Hmm.. Th ecurrent BK tree contains much of the anonvma stuff, so this 
> might actually be a serious VM performance regression. That could 
> effectively be hiding whatever problem you saw.
> 
> Andrea: have you tested under low memory and high fs load? Steven has 384M
> or RAM, which _will_ cause a lot of VM activity when doing a full kernel
> BK clone + undo + pull, which is what his test script ends up doing...

An easy way to verify for Steven is to give a quick spin to 2.6.5-aa5
and see if it's slow too, that will rule out the anon-vma changes
(for completeness: there's a minor race in 2.6.5-aa5 fixed in my current
internal tree, I posted the fix to l-k separately, but you can ignore
the fix for a simple test, it takes weeks to trigger anyways and you
need threads to trigger it and I've never seen threaded version control
systems so I doubt BK is threaded).

In general a "slowdown" cannot be related to anon-vma (unless it's a
minor merging error), that's a black and white thing, it doesn't touch
the vm heuristics and it will only speed the fast paths up plus it will
save some tons of ram in the big systems. Pratically no change should be
measurable on a small system (unless it uses an heavy amount of cows, in
which case it will improve things, it should never hurt).  As for being
tested, it is very well tested on the small desktops too. Probably the
only thing to double check is that there was no minor merging error that
could have caused this.

> It would be good to test going back to the kernel that saw the "immediate 
> problem", and try that version without CONFIG_PREEMPT. 

Agreed.

Thanks.