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();
> > + else
> > + usleep_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
