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 Sunday 16 May 2004 02:38 pm, Andrea Arcangeli wrote:
> On Sun, May 16, 2004 at 09:28:21AM -0600, Steven Cole wrote:
> > 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.
> 
> 2.6.3 is quite old, as Andrew is wondering about, this is more likely a
> vm heuristic issue if something, it cannot be anon-vma related.
> 
> btw, if you've 2.6.3 you should download just two patches to go to
> 2.6.5.
> 
> 
Sure, but I also wanted to beat the ppp paths while I did other things.
I've been using bk to keep a current kernel, and my older source
trees were sitting on another (disconnected) disk.  The 2.6.3 is
the vendor kernel.

That download succeeded, better than I've experienced for a long
time, possibly due to not having PREEMPT set.  With PREEMPT and
2.6.x kernels, I had been getting this, and ppp would stop moving data.

May 13 18:09:30 spc kernel: serial8250: too much work for irq10

I did build boot and run 2.6.5-aa5 (which had -aa4 in the EXTRAVERSION),
but the results for the bk exerciser script were similar to 2.6.6-current:

-----------------------------
2.6.6-current:

time bk clone -qlr40514130hBbvgP4CvwEVEu27oxm46w testing-2.6 foo
290.48user 96.76system 15:00.85elapsed 42%CPU 

(cd foo; time bk pull -q)
402.74user 254.98system 23:25.43elapsed 46%CPU 
------------------------------
2.6.5-aa5:

time bk clone -qlr40514130hBbvgP4CvwEVEu27oxm46w testing-2.6 foo
290.78user 94.29system 16:06.73elapsed 39%CPU 

(cd foo; time bk pull -q)
401.82user 234.05system 23:36.32elapsed 44%CPU 

------------------------------
2.6.3-4mdk (repeated run)

time bk clone -qlr40514130hBbvgP4CvwEVEu27oxm46w testing-2.6 foo
288.71user 58.47system 10:57.37elapsed 52%CPU 

(cd foo; time bk pull -q)
397.94user 186.18system 17:24.73elapsed 55%CPU 

Anyway, although the regression for my particular machine for this
particular load may be interesting, the good news is that I've seen
none of the failures which started this whole thread, which are relatively
easily reproduceable with PREEMPT set.  

Perhaps  PREEMPT should be renamed to BUG_FLUSH. :)

Steven