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?
mkb.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
