[lkml]   [2006]   [Jun]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] IPMI: use schedule in kthread
    Andrew Morton wrote:
    > On Mon, 26 Jun 2006 09:08:19 -0500
    > 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 <>
    >> 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?
    The IPMI physical interfaces in generally really suck. The most common
    are byte at a time interfaces without interrupts that generally take in
    the 500 microsecond per byte range.

    This thread is an attempt to improve the performance of these
    interfaces. It is very low priority and wakes up when the IPMI
    interface is doing something. It basically spins looking for IPMI
    activity at nice level 19 to help improve the performance of the
    interface. So basically, it chews CPU, but should be preempted by
    anything else that is scheduled to run. However, just calling udelay(1)
    caused scheduling problems; users were reporting soft lockups, jerky
    mouse movement, and keyboard problems if the IPMI interface was very
    busy. Adding a schedule here seems to fix those problems, and I'm
    assuming they are falling into your third scenario above.

    Any suggestions on better ways to fix this?


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2006-06-26 21:54    [W:0.022 / U:33.824 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site