Re: [PATCH] IPMI: use schedule in kthread

[Andrew Morton <akpm@osdl.org>]

On Mon, 26 Jun 2006 14:49:37 -0500
Matt Domsch <Matt_Domsch@dell.com> wrote:

> On Mon, Jun 26, 2006 at 12:00:48PM -0700, Andrew Morton wrote:
> > On Mon, 26 Jun 2006 09:08:19 -0500
> > MAILER-DAEMON@osdl.org wrote:
> > 
> > > The kthread used to speed up polling for IPMI was using udelay
> > > when the lower-level state machine told it to do a short delay.
> > > This just used CPU and didn't help scheduling, thus causing bad
> > > problems with other tasks.  Call schedule() instead.
> > > 
> > > Signed-off-by: Corey Minyard <minyard@acm.org>
> > > 
> > > Index: linux-2.6.17/drivers/char/ipmi/ipmi_si_intf.c
> > > ===================================================================
> > > --- linux-2.6.17.orig/drivers/char/ipmi/ipmi_si_intf.c
> > > +++ linux-2.6.17/drivers/char/ipmi/ipmi_si_intf.c
> > > @@ -809,7 +809,7 @@ static int ipmi_thread(void *data)
> > >  			/* do nothing */
> > >  		}
> > >  		else if (smi_result == SI_SM_CALL_WITH_DELAY)
> > > -			udelay(1);
> > > +			schedule();
> > >  		else
> > >  			schedule_timeout_interruptible(1);
> > >  	}
> > 
> > calling schedule() isn't a lot of use either.
> > 
> > If CONFIG_PREEMPT it's of no benefit and will just chew CPU.
> > 
> > If !CONFIG_PREEMPT && !need_resched() then it's a no-op and will chew CPU.
> > 
> > If !CONFIG_PREEMPT && need_resched() then yes, it'll schedule away.  This
> > is pretty much the only time that a simple schedule() is useful.
> > 
> > 
> > What are we actually trying to do in here?
> 
> Make up for a lack of poor hardware design.  Most IPMI controllers
> that use the standard-specified KCS interface don't implement
> interrupts to signal data availability, and its a character-at-a-time
> interface.

ah, OK, you're screwed ;) There's no fix for that, so blowing CPU while
offering reschedule opportunities is better than just blowing CPU.