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

[Steven Cole <elenstev@mesatop.com>]

On Saturday 15 May 2004 11:22 pm, Andrea Arcangeli wrote:
> 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).

I'm getting the linux-2.6.5.tar.bz2 file (already got 2.6.5-aa2) via ppp,
while running the bk test script on 2.6.6-current and no PREEMPT.
That takes a while on 56k dialup.  I'll leave all that running while
I go hiking.

> 
> 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.

Andrea, I did see a significant slowdown with Andy's test script (with DMA on)
on my timed test of 2.6.6-current vs 2.6.3.

> 
> > 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.
> 
> 

Yep, later this evening, I hope.

Steven