Messages in this thread | | | From | Steven Cole <> | Subject | Re: 1352 NUL bytes at the end of a page? (was Re: Assertion `s && s->tree' failed: The saga continues.) | Date | Sun, 16 May 2004 15:19:03 -0600 |
| |
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 - 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/
| |