Re: [PATCH] IPMI: use schedule in kthread

Andrew Morton
2006-06-26T19:59:27Z

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.