Messages in this thread | | | Date | Mon, 26 Jun 2006 14:49:37 -0500 | From | Matt Domsch <> | Subject | Re: [PATCH] IPMI: use schedule in kthread |
| |
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.
Without this kernel thread, ordinary operations (ipmitool sensor list) would take 30 seconds, essentially one character transfer per timer tick. Starting applications that would read a lot of IPMI data would take 5 minutes. Doing a firmware flash would take 15 minutes.
With the kernel thread, these ops drop to 5-7 seconds, <1 minute, and ~1.5 minutes respectively. It does this by polling at a rate faster than the timer tick, in a low-priority kernel thread, any time a command is outstanding to the controller. If no commands are outstanding, it goes to sleep for a tick, then wakes up (in case the controller itself generates an event so we can capture that).
The trouble is, with udelay(1), it could consume the CPU while waiting for a command to complete on the controller, without letting other tasks run. This exhibited itself as jittery mouse movement as well as soft lockup messages.
We need to be able to poll at faster-than-timer-tick rates, yet let other higher-priority apps run. Hence the schedule(). We're open to other suggestions, but this seemed minimally intrusive while accomplishing the goal. No more soft lockups or jittery mice.
Thanks, Matt
-- Matt Domsch Software Architect Dell Linux Solutions linux.dell.com & www.dell.com/linux Linux on Dell mailing lists @ http://lists.us.dell.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |