Start irqbalance by default

Chuck Short chuck.short at canonical.com
Tue Jan 19 15:55:30 GMT 2010


Sebastian Bacher did some tests with respect to boot performance. He 
said that irqbalance causes no visible activity which seems to not make 
a difference to the boot performance. This was done on the mini config 
(ie atom cpu).

Regards
chuck

Robbie Williamson wrote:
> My main concern is the affect on boot performance.  I'd like to see
> bootchart data showing it doesn't slow down our boot on our reference
> hardware (Dell Mini 10v SSD and HDD).  If we can be confident that
> performance is not negatively affected, then I'm personally fine with
> starting it by default.
>
> -Robbie
>
> On Fri, 2010-01-15 at 14:38 +0100, Soren Hansen wrote: 
>   
>> On Mon, Jan 11, 2010 at 11:23:43AM +0000, Matt Zimmerman wrote:
>>     
>>> I'm not sure why it needs to run all the time, though, rather than
>>> (say) as a cron job.  It has a --oneshot option which might be
>>> suitable for this.
>>>       
>> FWIW, it automatically switches to oneshot mode on single-CPU,
>> multi-core systems, so it only sticks around on "actual" multi-CPU
>> systems. I think those are a rare breed among desktop systems.
>>
>>     
>>>> Does userspace have more information about which processes are
>>>> running and what they are going to do? If so, doesn't that involve
>>>> more IPC and thus wakeups? If not, why isn't that alternative
>>>> strategy implemented in the kernel itself (right now it seems that
>>>> the scheduling would be done at two places?)
>>>>         
>>> It's looking at statistical behavior, e.g. how many IRQs particular
>>> devices have generated over a period of minutes or hours, and uses
>>> that information to provide the kernel with scheduling hints.  I think
>>> running it a few times per hour at most would be sufficient.
>>>       
>> I don't think a rescheduling interval of more than a minute is really
>> very useful.
>>
>>     
>>>> Chuck, did you actually intend to install this on all desktop systems
>>>> as well, or just servers (where performance might matter more).
>>>>         
>>> It seems appropriate for both.
>>>       
>> I concur.
>>
>>     
>
>
>   




More information about the ubuntu-devel mailing list