public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jean Delvare <jdelvare@suse.de>
To: Andrew Morton <akpm@linux-foundation.org>
Cc: minyard@acm.org, Linux Kernel <linux-kernel@vger.kernel.org>,
	Martin Wilck <martin.wilck@ts.fujitsu.com>,
	OpenIPMI Developers <openipmi-developer@lists.sourceforge.net>
Subject: Re: [PATCH] IPMI: Add parameter to limit CPU usage in kipmid
Date: Thu, 17 Dec 2009 11:36:47 +0100	[thread overview]
Message-ID: <200912171136.48086.jdelvare@suse.de> (raw)
In-Reply-To: <20091216134252.868ea5bf.akpm@linux-foundation.org>

Hi Andrew,

Thanks for your comments.

Le mercredi 16 décembre 2009 22:42, Andrew Morton a écrit :
> On Wed, 16 Dec 2009 15:23:54 -0600
> Corey Minyard <minyard@acm.org> wrote:
> 
> > From: Martin Wilck <martin.wilck@ts.fujitsu.com>
> > 
> > In some cases kipmid can use a lot of CPU.
> 
> Why is that?  Without this information it is hard for others to suggest
> alternative implementations.

Quoting Greg KH as he was investigating this issue:

"This looks to be a difference in the way the hardware works from
different ipmi controllers. Some allow for sleeping in an
interruptable state, and others do not, and can not have their delays
interrupted. Because of this, the process is put into uninterruptable
sleep mode, which causes a 'fake' system load increase on those types
of hardware controllers."

> >  This adds a way to tune
> > the CPU used by kipmid to help in those cases.  By setting
> > kipmid_max_busy_us to a value between 100 and 500, it is possible to
> > bring down kipmid CPU load to practically 0 without loosing too much
> > ipmi throughput performance.  Not setting the value, or setting the
> > value to zero, operation is unaffected.
> 
> Requiring the addition of a module parameter is regrettable.  It'd be
> better if the code "just works".

That's right, it'd be better. But my understanding is that there is
no way to figure out automatically when the parameter is needed nor
its optimal value other than by trial and error. I'd love to be
proven wrong though.

> > Signed-off-by: Martin Wilck <martin.wilck@ts.fujitsu.com>
> > Cc: Jean Delvare <jdelvare@suse.de>
> > Signed-off-by: Corey Minyard <cminyard@mvista.com>
> > 
> > --- linux-2.6.29.4/drivers/char/ipmi/ipmi_si_intf.c	2009-05-19 01:52:34.000000000 +0200
> > +++ linux-2.6.29-rc8/drivers/char/ipmi/ipmi_si_intf.c	2009-06-04 15:30:34.855398091 +0200
> > @@ -297,6 +297,9 @@
> >  static int force_kipmid[SI_MAX_PARMS];
> >  static int num_force_kipmid;
> >  
> > +static unsigned int kipmid_max_busy_us[SI_MAX_PARMS];
> > +static int num_max_busy_us;
> > +
> >  static int unload_when_empty = 1;
> >  
> >  static int try_smi_init(struct smi_info *smi);
> > @@ -927,23 +930,56 @@
> >  	}
> >  }
> >  
> > +#define ipmi_si_set_not_busy(timespec) \
> > +	do { (timespec)->tv_nsec = -1; } while (0)
> > +#define ipmi_si_is_busy(timespec) ((timespec)->tv_nsec != -1)
> 
> These could have been implemented in C.  It's better that way.

+1, inline functions would be more readable.

I'll let Corey and maybe Martin comment on the rest, as the code is
not mine and I am not familiar with it.

-- 
Jean Delvare
Suse L3

  parent reply	other threads:[~2009-12-17 10:36 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-12-16 21:23 [PATCH] IPMI: Add parameter to limit CPU usage in kipmid Corey Minyard
2009-12-16 21:42 ` Andrew Morton
2009-12-17  7:12   ` Michael Tokarev
2009-12-17 10:36   ` Jean Delvare [this message]
2009-12-17 18:34     ` Corey Minyard
2009-12-17 20:07       ` Jean Delvare
2009-12-17 22:08         ` Corey Minyard
2009-12-19 13:56           ` Jean Delvare
2010-01-14 14:02             ` Jean Delvare

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=200912171136.48086.jdelvare@suse.de \
    --to=jdelvare@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=martin.wilck@ts.fujitsu.com \
    --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