On Wed, May 25, 2005 at 06:44:37PM +0200, Matthias Buelow wrote: > Kris Kennaway wrote: > > >>interrupt total rate > >>irq1: atkbd0 586 0 > >>irq13: npx0 1 0 > >>irq14: ata0 94 0 > >>irq17: wi0 54 0 > >>irq20: fxp0 atapci1 62079 99 > >>irq21: uhci0 ehci0 1 0 > >>irq22: uhci1 1102 1 > >>lapic0: timer 1246549 1994 > >>lapic1: timer 1246427 1994 > >>Total 2556893 4091 > >>The only relevant conflict I could see is irc 20; but I had already > >>tested that by removing fxp0 from the kernel. > > > >I wonder if USB is causing the problem all on its own..since that was > >the culprit in other situations when it was being triggered by virtue > >of interrupt sharing. Any chance you can try a non-USB mouse and > >remove USB from your kernel? > > Ok, now USB (both uhci and ehci) is gone. The problem is still the > same. vmstat -i: > > interrupt total rate > irq1: atkbd0 1324 3 > irq12: psm0 8562 21 > irq13: npx0 1 0 > irq14: ata0 94 0 > irq17: wi0 381 0 > irq20: fxp0 atapci1 61956 154 > lapic0: timer 801433 1993 > lapic1: timer 801292 1993 > Total 1675043 4166 > > To be frank, I do not believe it's got anything to do with locking or > interrupts. It somehow seems just like the scheduler is doing a bad job > of balancing interactive processes vs. disk i/o. I've seen the same > stuff for years on NetBSD (until they changed scheduling around 1.5 or > so) and Linux (until 2.4 kernels). During that time FreeBSD didn't > exhibit these symptoms and only in 5.x have I seen that kind of > behaviour creep back in. Has the classic scheduler been changed > somehow? Maybe I should try and see if the problem persists with the > ULE scheduler?
Others don't see this though, and in other cases it was *definitively proven* to be caused by the issue I mentioned. I'll have to think more about what to try next..thanks for running the tests. Kris
pgpWStVHX8C2v.pgp
Description: PGP signature
