Linux OS Service ‘irqbalance’

irqbalance is a Linux daemon that distributes interrupts over among the processors and cores in your computer system. The design goal of irqbalance is to do find a balance between power savings and optimal performance. To a large degree, the work irqbalance does is invisible to you. The daemon balances savings in power consumption with performance.

irqbalance is relevant on multiprocessor x86, x86_64, and AMD systems. The irqbalance configuration file /etc/sysconfig/irqbalance allows the selection of which CPU’s which may be assigned which interrupts. Below is a sample configuration file from RHEL 7 system.

# cat /etc/sysconfig/irqbalance
# irqbalance is a daemon process that distributes interrupts across
# CPUS on SMP systems. The default is to rebalance once every 10
# seconds. This is the environment file that is specified to systemd via the
# EnvironmentFile key in the service unit file (or via whatever method the init
# system you're using has.
#
# ONESHOT=yes
# after starting, wait for a minute, then look at the interrupt
# load and balance it once; after balancing exit and do not change
# it again.
#IRQBALANCE_ONESHOT=

#
# IRQBALANCE_BANNED_CPUS
# 64 bit bitmask which allows you to indicate which cpu's should
# be skipped when reblancing irqs. Cpu numbers which have their
# corresponding bits set to one in this mask will not have any
# irq's assigned to them on rebalance
#
#IRQBALANCE_BANNED_CPUS=

#
# IRQBALANCE_ARGS
# append any args here to the irqbalance daemon as documented in the man page
#
#IRQBALANCE_ARGS=

The configurable items are discussed below:

Parameter Default Description
ONESHOT NO After the system has been running for 10 seconds, adjust the interrupt service assignments once and then exit.
IRQ_AFFINITY_MASK empty A bitmask whose 1-bits indicate which CPU’s should be skipped when balancing the interrupt requests.  This allows a given set of CPU’s to not be bothered by any interrupt service load.  This setting is for legacy compatibility only; use IRQBALANCE_BANNED_CPUS instead.
IRQBALANCE_BANNED_INTERRUPTS empty A space-delimited list of the interrupt request levels which irqbalance should ignore when balancing.  This allows an interrupt to be kept on the same CPU; this can improve performance by increasing the likelihood the interrupt service code and context are kept in the high-speed cache memory of the CPU and avoiding expensive cache-line refreshes.
IRQBALANCE_BANNED_CPUS empty A bit mask whose 1-bits indicate those CPU’s which should never have an interrupt service assigned to them.  This can improve performance by removing the interrupt service overhead, especially the CPU L1 and L2 cache reloads.

Service Details

– Init.d script location -> /etc/init.d/irqbalance
– Example of “chkconfig –list [service]”

# chkconfig --list irqbalance
irqbalance      0:off   1:off   2:on    3:on    4:on    5:on    6:off

– Available service usage options:

# service irqbalance
Usage: /etc/init.d/irqbalance {start|stop|status|restart|reload|condrestart}
# service irqbalance start
Starting irqbalance:                                       [  OK  ]
# service irqbalance stop
Stopping irqbalance:                                       [  OK  ]
# service irqbalance status
irqbalance (pid 14857) is running...
# service irqbalance restart
Stopping irqbalance:                                       [  OK  ]
Starting irqbalance:                                       [  OK  ]
# service irqbalance reload
Stopping irqbalance:                                       [  OK  ]
Starting irqbalance:                                       [  OK  ]
# service irqbalance condrestart

– Which daemons does it run : /usr/sbin/irqbalance
– Which modules does it load : none

Other Information

– RPM packages : irqbalance-[version]-[release]
e.g: irqbalance-1.0.4-10.el6.x86_64

– Configuration file : /etc/sysconfig/irqbalance
– Project Homepage: https://github.com/Irqbalance/irqbalance

When Should Not To Use

In most of time, irqbalance service is enabled and should be used unless:

  • Manually pinning apps/IRQ’s to specific cores for a very good reason (low latency, realtime requirements, etc.)
  • Virtual Guests. It does not really make sense because unless you are pinning the guest to specific CPUs and IRQs and dedicated net/storage hardware, you will likely not see the benefits you would on bare metal.
Related Post