Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)

Matthias Buelow mkb at
Wed May 25 09:44:25 PDT 2005

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?


More information about the freebsd-stable mailing list