2.6.27/2.6.28: irqbalance dies shortly after starting the daemon on x86 but not x86_64, why?

2.6.27/2.6.28: irqbalance dies shortly after starting the daemon on x86 but not x86_64, why?

[Justin Piszcz]

(same on both x86 and x86_64):
# cat /etc/default/irqbalance
#Configuration for the irqbalance daemon

#Should irqbalance be enabled?
ENABLED=1
#Balance the IRQs only once?
ONESHOT="0"

========
my x86 system:
========

# /etc/init.d/irqbalance start
Starting SMP IRQ Balancer: irqbalance.

# ps auxww | grep -i irqbalance
root      4570  0.0  0.0   2536   436 ?        Ss   07:07   0:00 /usr/sbin/irqbalance

# sleep 300; ps auxww | grep -i irqbalance
#

=========
On my x86_64 systems:
=========

$ ps auxww | grep -i irqbalance
root      2769  0.0  0.0   8828   492 ?        Ss   Dec27   0:06 /usr/sbin/irqbalance
$ ps auxww | grep -i irqbalance
root      2918  0.0  0.0   8828   520 ?        Ss   Dec22   0:18 /usr/sbin/irqbalance

Is there a bug on x86?

Justin.

Re: 2.6.27/2.6.28: irqbalance dies shortly after starting the daemon on x86 but not x86_64, why?

[Arjan van de Ven]

Justin Piszcz wrote:
> (same on both x86 and x86_64):
> # cat /etc/default/irqbalance
> #Configuration for the irqbalance daemon
> 
> #Should irqbalance be enabled?
> ENABLED=1
> #Balance the IRQs only once?
> ONESHOT="0"


which version of irqbalance is this?

Re: 2.6.27/2.6.28: irqbalance dies shortly after starting the daemon on x86 but not x86_64, why?

[Justin Piszcz]

On Fri, 2 Jan 2009, Arjan van de Ven wrote:

> Justin Piszcz wrote:
>> (same on both x86 and x86_64):
>> # cat /etc/default/irqbalance
>> #Configuration for the irqbalance daemon
>> 
>> #Should irqbalance be enabled?
>> ENABLED=1
>> #Balance the IRQs only once?
>> ONESHOT="0"
>
>
> which version of irqbalance is this?
>

$ dpkg -l | grep -i irqbalance
ii  irqbalance                           0.55-2.4                      Daemon to balance interrupts for SMP systems

Kyle stated:
> If there is only one cache domain, ie: one physical cpu socket with two
> cores sharing a cache, then irqbalance will return after the initial
> balance since it would be pointless to continue running. (It forces
> itself into oneshot mode.)

The CPU = E6700 so yep, so if there is one physical socket with 4 cores it
keeps?  For it to keep and not oneshot you need > 2 cores?

Justin.

Re: 2.6.27/2.6.28: irqbalance dies shortly after starting the daemon on x86 but not x86_64, why?

[Kyle McMartin]

On Fri, Jan 02, 2009 at 07:32:21PM -0500, Justin Piszcz wrote:
> The CPU = E6700 so yep, so if there is one physical socket with 4 cores it
> keeps?  For it to keep and not oneshot you need > 2 cores?
>

It depends... if your 4-core is laid out with four cores sharing one
external cache, then it will terminate, if, say you had 4 cores with
each pair sharing a cache (so two external caches) then it would
continue as a daemon. (If you had 2 sockets with a processor in each
one, it would continue running as well no matter how many cores on
each.)

If you run irqbalance --debug, it will show you the topology it detects.
If you have multiple cache domains, and it is still exiting, then we
have a bug. :)

cheers, Kyle

Re: 2.6.27/2.6.28: irqbalance dies shortly after starting the daemon on x86 but not x86_64, why?

[Justin Piszcz]

On Fri, 2 Jan 2009, Kyle McMartin wrote:

> On Fri, Jan 02, 2009 at 07:32:21PM -0500, Justin Piszcz wrote:
>> The CPU = E6700 so yep, so if there is one physical socket with 4 cores it
>> keeps?  For it to keep and not oneshot you need > 2 cores?
>>
>
> It depends... if your 4-core is laid out with four cores sharing one
> external cache, then it will terminate, if, say you had 4 cores with
> each pair sharing a cache (so two external caches) then it would
> continue as a daemon. (If you had 2 sockets with a processor in each
> one, it would continue running as well no matter how many cores on
> each.)
>
> If you run irqbalance --debug, it will show you the topology it detects.
> If you have multiple cache domains, and it is still exiting, then we
> have a bug. :)
>
> cheers, Kyle
>

Looks correct, just a single cache domain on this host-- thanks.

#  irqbalance --debug
Package 0:  cpu mask is 00000003 (workload 0)
         Cache domain 0: cpu mask is 00000003  (workload 0)
                 CPU number 0  (workload 0)
                 CPU number 1  (workload 0)
Interrupt 315 (class ethernet) has workload 20 
Interrupt 0 (class timer) has workload 0 
Interrupt 314 (class storage) has workload 11 
Interrupt 16 (class legacy) has workload 216 
Interrupt 17 (class legacy) has workload 122 
Interrupt 23 (class legacy) has workload 26 
Interrupt 19 (class legacy) has workload 18 
Interrupt 1 (class legacy) has workload 1 
Interrupt 18 (class legacy) has workload 0 
Interrupt 9 (class legacy) has workload 0 
Interrupt 6 (class legacy) has workload 0



-----------------------------------------------------------------------------
IRQ delta is 3963 
Package 0:  cpu mask is 00000003 (workload 2474)
         Cache domain 0: cpu mask is 00000003  (workload 2474)
                 CPU number 0  (workload 1343)
                   Interrupt 314 (storage/13)
                   Interrupt 16 (legacy/1080)
                   Interrupt 19 (legacy/245)
                   Interrupt 18 (legacy/0)
                   Interrupt 6 (legacy/0)
                 CPU number 1  (workload 1131)
                   Interrupt 315 (ethernet/132)
                   Interrupt 17 (legacy/689)
                   Interrupt 23 (legacy/291)
                   Interrupt 1 (legacy/14)
                   Interrupt 9 (legacy/0)

Re: 2.6.27/2.6.28: irqbalance dies shortly after starting the daemon on x86 but not x86_64, why?

[Kyle McMartin]

On Tue, Dec 30, 2008 at 07:26:30AM -0500, Justin Piszcz wrote:
> (same on both x86 and x86_64):
> # cat /etc/default/irqbalance
> #Configuration for the irqbalance daemon
>
> #Should irqbalance be enabled?
> ENABLED=1
> #Balance the IRQs only once?
> ONESHOT="0"
>

If there is only one cache domain, ie: one physical cpu socket with two
cores sharing a cache, then irqbalance will return after the initial
balance since it would be pointless to continue running. (It forces
itself into oneshot mode.)

regards, Kyle