SUSE Support

Here When You Need Us

kipmi uses lots of cpu time

This document (7003352) is provided subject to the disclaimer at the end of this document.

Environment

SUSE Linux Enterprise Server 10 Service Pack 3
SUSE Linux Enterprise Server 10 Service Pack 2
SUSE Linux Enterprise Server 11

Situation

Since SUSE Linux Enterprise Server 10 SP2 kipmi seems to be one of the most expensive processes on some machines. Example:

top - 13:00:35 up 4 days, 23:13,  4 users,  load average: 0.00, 0.05, 0.07
Tasks: 123 total,   1 running, 122 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.2%sy,  0.0%ni, 99.8%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:   1027744k total,   987784k used,    39960k free,   192668k buffers
Swap:  1052216k total,      108k used,  1052108k free,   547428k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 3732 root      34  19     0    0    0 S    2  0.0  94:22.79 kipmi0
    1 root      16   0   796  308  256 S    0  0.0   0:02.36 init
[...]



NOTE: This looks bad, but it is not a real problem, as kipmi only uses idle cycles. The more busy the machine is, less cycles are used. This does NOT increase the machine's load, nor does it affect response time. This is just a cosmetical issue.

Reason is that with SLES10 SP2 ipmi is almost fully supported whereas it wasn't with older versions. 
While some machines are affected, others are not. On machines using the outdated KCS interface kipmi needs to loop fast to gather data from the interface. There's no way to trigger a interrupt, as KCS doesn't provide that.

Resolution

This issue is fixed with SLES10-SP3 kernel 2.6.16.60-0.62.1 and above as well as on SLES11-SP1.
Please update to these versions.

Note that by default the old behavior is active.
To enable the fix create a file /etc/modprobe.conf.d/ipmi.conf with a line:

options ipmi_si kipmid_max_busy_us=100

and restart the daemon with:

/etc/init.d/ipmi restart

Useful values for kipmid_max_busy_us are 100 to 500. Higher values result in faster response, but increase the chance that ipmi starts to eat up idle cycles again. 500 however worked fine on a testsystem. Please test and tune accordingly.

Additional Information

For older kernels, there is a workaround:

It's possible to use ipmi without running the kipmi process. Drawback is that all ipmi usage is slowed down by at least factor 10, meaning, that e.g. a ipmi sensor query will take several minutes instead of seconds.


To disable the kipmi process for kernels older than 2.6.16.60-0.62.1, add a file below /etc/modprobe.conf.d/  (filename is irrelevant) with a line:

options ipmi_si force_kipmid=0

After that run the commands:

modprobe -r ipmi_si
depmod -a
modprobe ipmi_si

Disclaimer

This Support Knowledgebase provides a valuable tool for SUSE customers and parties interested in our products and solutions to acquire information, ideas and learn from one another. Materials are provided for informational, personal or non-commercial use within your organization and are presented "AS IS" WITHOUT WARRANTY OF ANY KIND.

  • Document ID:7003352
  • Creation Date: 26-May-2009
  • Modified Date:28-Sep-2022
    • SUSE Linux Enterprise Server

< Back to Support Search

For questions or concerns with the SUSE Knowledgebase please contact: tidfeedback[at]suse.com

tick icon

SUSE Support Forums

Get your questions answered by experienced Sys Ops or interact with other SUSE community experts.

tick icon

Support Resources

Learn how to get the most from the technical support you receive with your SUSE Subscription, Premium Support, Academic Program, or Partner Program.

tick icon

Open an Incident

Open an incident with SUSE Technical Support, manage your subscriptions, download patches, or manage user access.