On Tue, Oct 08, 2019 at 11:49:15AM +0200, Pavel Machek wrote:
Hi!
@@ -1013,11 +1016,20 @@ static int ipmi_thread(void *data) spin_unlock_irqrestore(&(smi_info->si_lock), flags); busy_wait = ipmi_thread_busy_wait(smi_result, smi_info, &busy_until);
if (smi_result == SI_SM_CALL_WITHOUT_DELAY)
if (smi_result == SI_SM_CALL_WITHOUT_DELAY) { ; /* do nothing */
else if (smi_result == SI_SM_CALL_WITH_DELAY && busy_wait)schedule();else if (smi_result == SI_SM_IDLE) {
} else if (smi_result == SI_SM_CALL_WITH_DELAY && busy_wait) {/** In maintenance mode we run as fast as* possible to allow firmware updates to* complete as fast as possible, but normally* don't bang on the scheduler.*/if (smi_info->in_maintenance_mode)schedule();elseusleep_range(100, 200);} else if (smi_result == SI_SM_IDLE) {This is quite crazy code. usleep() will need to do magic with high resolution timers to provide 200usec sleep... when all you want to do is unload the scheduler.
cond_resched() should be okay to call in a loop, can the code use that instead?
According to Tejun Heo, spinning in a loop sleeping was causing all sorts of issues with banging on scheduler locks on systems with lots of cores. I forgot to add him to the CC on the patch, adding him now for comment.
If cond_resched() would work, though, I'd be happy with that, it's certainly simpler.
-corey
Best regards, Pavel
-- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html