Re: [Openipmi-developer] IPMI driver performance problem

[Corey M. <mi...@ac...>]

Nathan Scott wrote:
>
> So, I'm kinda stuck I guess.  It is impacting performance for
> us (the oprofile example I gave earlier is a 2 CPU NAS box, so
> we lose one CPU while kipmid is doing its thing, which is not
> helping the software thats meant to be consuming CPU resources
> on the machine at those times - nfsd's and constant rsync's to
> a secondary NAS).  That 31% was 31% of the CPU events sampled
> across both CPUs - the oprofile run was for 5 seconds, and was
> started _after_ the initial spike was detected (so 31% in that
> worst case was probably not the whole picture either).
>   
This shouldn't significantly affect performance.  kipmid runs at nice 
level 19, meaning that basically everything else is more important than 
it.  It could be made a little bit lower priority by setting the 
scheduling policy to SCHED_IDLE, but that wouldn't make a big difference.

There's a difference between running and taking away performance.  It 
shouldn't be taking away performance.  It may be using CPU, but only 
when the other processes are idle, unless you have nice-ed them to lower 
priorities (bigger nice numbers).

If it is truly affecting performance, then something else is wrong and 
we need to figure it out.

> Oh well, so it goes.  If you could try again to get hardware
> that supports interrupt-driven IPMI processing out there (even
> if disabled by default, or something, to avoid the issues you
> had with those other OSes) - that would be wonderful and very
> much appreciated.
>   
Yeah, this is a pain.  Interrupts really improve things, but there are 
almost never available because of this.  It would be nice to have a BIOS 
option to turn them on.

-corey