Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 8 Oct 2019 07:19:41 -0500
From:   Corey Minyard <cminyard@mvista.com>
To:     Pavel Machek <pavel@denx.de>, Tejun Heo <tj@kernel.org>
Cc:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        linux-kernel@vger.kernel.org, stable@vger.kernel.org,
        Sasha Levin <sashal@kernel.org>
Subject: Re: [PATCH 4.19 012/106] ipmi_si: Only schedule continuously in the
 thread in maintenance mode
Message-ID: <20191008121941.GA14232@t560>
Reply-To: cminyard@mvista.com
References: <20191006171124.641144086@linuxfoundation.org>
 <20191006171130.485953894@linuxfoundation.org>
 <20191008094915.GC608@amd>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20191008094915.GC608@amd>
User-Agent: Mutt/1.9.4 (2018-02-28)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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