Messages in this thread | | | Date | Sun, 16 May 2004 07:22:20 +0200 | From | Andrea Arcangeli <> | Subject | Re: 1352 NUL bytes at the end of a page? (was Re: Assertion `s && s->tree' failed: The saga continues.) |
| |
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |