[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-id: <49C8DB54.4010200@acm.org>
Date: Tue, 24 Mar 2009 08:08:36 -0500
From: Corey Minyard <minyard@....org>
To: Martin Wilck <martin.wilck@...itsu-siemens.com>
Cc: Greg KH <greg@...ah.com>,
"openipmi-developer@...ts.sourceforge.net"
<openipmi-developer@...ts.sourceforge.net>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [Openipmi-developer] Improving IPMI performance under load
Martin Wilck wrote:
> Hi Corey,
>
> yesterday I posted some results about the IPMI performance under CPU
> load, which can be up to 25 times slower than in an idle system. I think
> it might be worthwhile to try to improve that behavior as well.
>
Yes, that would be expected, as kipmid would never be scheduled in a
busy system, and it would just be the timer driving things.
> I made a variation of my patch which introduces a second parameter
> (kipmid_min_busy) that causes kipmid not to call schedule() for a
> certain amount of time. Thus if there's IPMI traffic pending, kipmid
> will busy-loop for kipmid_min_busy seconds, then starting to schedule()
> in each loop as it does now, and finally go to sleep when
> kipmid_max_busy is reached. At the same time, I changed the nice value
> of kipmid from 19 to 0.
>
I would guess that changing the nice value is the main thing that caused
the difference. The other changes probably didn't make as big a difference.
> With this patch and e.g. min_busy=100 and max_busy=200, there is no
> noticeable difference any more between IPMI performance with and without
> CPU load.
>
> The patch + results still need cleanup, therefore I am not sending it
> right now. Just wanted to hear what you think.
>
I'm ok with tuning like this, but most users are probably not going to
want this type of behavior.
-corey
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists