From: Martin Wilck <martin.wilck@fujitsu-siemens.com>
To: Corey Minyard <minyard@acm.org>
Cc: Greg KH <greg@kroah.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"openipmi-developer@lists.sourceforge.net"
<openipmi-developer@lists.sourceforge.net>
Subject: Re: [PATCH] limit CPU time spent in kipmid
Date: Mon, 23 Mar 2009 14:25:37 +0100 [thread overview]
Message-ID: <49C78DD1.30406@fujitsu-siemens.com> (raw)
In-Reply-To: <49C3E03E.10506@acm.org>
Corey Minyard wrote:
>>> It's actually already sort of self-tuning. kipmid sleeps unless there is
>>> IPMI activity. It only spins if it is expecting something from the
>>> controller.
The self-tuning is fine (as long as there is no CPU load, which may slow
down stuff a lot, see my other posting). But on systems with many
sensors it will lead to considerable CPU time shown in "top" and other
tools for kipmid. And this confuses users. Users think that this is the
hardware vendor's fault - that's why I am sending this patch (if you so
wish, it is indeed the vendor's fault to use the outdated KCS interface
- but that's a different discussion, please let's keep it separate).
>>> I've been thinking about this a little more. Assuming that the self-tuning
>>> is working (and it appears to be working fine on my systems), that means
>>> that something is causing the IPMI driver to constantly talk to the
>>> management controller. I can think of three things:
>>>
>>> 1. The user is constantly sending messages to management controller.
This is what I did in my benchmark, of course. But also in real systems,
there are now many sensors (think dozens of DIMMs with several sensors
on each DIMM) and many events, causing constant IPMI traffic.
>>> 2. There is something wrong with the hardware, like the ATTN bit is
>>> stuck high, causing the driver to constantly poll the management
>>> controller.
>>> 3. The driver either has a bug or needs some more work to account for
>>> something the hardware needs it to do to clear the ATTN bit.
I think both 2.) and 3.) is not the case here.
>>> If it's #1 above, then I don't know if there is anything we can do about
>>> it. The patch Martin sent will simply slow things down.
True, but only a little bit. Please look at the numbers in my other posting.
Best regards
Martin
--
Martin Wilck
PRIMERGY System Software Engineer
FSC IP ESP DEV 6
Fujitsu Siemens Computers GmbH
Heinz-Nixdorf-Ring 1
33106 Paderborn
Germany
Tel: ++49 5251 525 2796
Fax: ++49 5251 525 2820
Email: mailto:martin.wilck@fujitsu-siemens.com
Internet: http://www.fujitsu-siemens.com
Company Details: http://www.fujitsu-siemens.com/imprint.html
next prev parent reply other threads:[~2009-03-23 13:25 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-03-19 16:27 [PATCH] limit CPU time spent in kipmid Martin Wilck
2009-03-19 21:31 ` Corey Minyard
2009-03-19 23:51 ` Greg KH
2009-03-20 15:30 ` Corey Minyard
2009-03-20 17:47 ` Greg KH
2009-03-20 18:28 ` Corey Minyard
2009-03-23 13:17 ` [PATCH] limit CPU time spent in kipmid (PREVIOUS WAS BROKEN) Martin Wilck
2009-03-23 15:32 ` Greg KH
2009-03-23 16:20 ` Martin Wilck
2009-03-23 20:39 ` Corey Minyard
2009-03-24 9:22 ` Martin Wilck
2009-03-24 9:30 ` Improving IPMI performance under load Martin Wilck
2009-03-24 13:08 ` [Openipmi-developer] " Corey Minyard
2009-03-24 13:21 ` Martin Wilck
2009-03-24 15:50 ` Matt Domsch
2009-03-24 17:15 ` Martin Wilck
2009-04-06 13:48 ` [PATCH] limit CPU time spent in kipmid (PREVIOUS WAS BROKEN) Martin Wilck
2009-06-04 18:39 ` [PATCH] limit CPU time spent in kipmid (version 4) Martin Wilck
2009-03-23 13:25 ` Martin Wilck [this message]
2009-03-19 22:41 ` [Openipmi-developer] [PATCH] limit CPU time spent in kipmid Bela Lubkin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49C78DD1.30406@fujitsu-siemens.com \
--to=martin.wilck@fujitsu-siemens.com \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=minyard@acm.org \
--cc=openipmi-developer@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox