Hi Corey,Yes, that would be expected, as kipmid would never be scheduled in a busy system, and it would just be the timer driving things.
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.
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.I'm ok with tuning like this, but most users are probably not going to want this type of behavior.
The patch + results still need cleanup, therefore I am not sending it right now. Just wanted to hear what you think.