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