Yeah, schedule() (and __sched prefixed) function call needed when we are waiting for some events. It would de wasteful to lose CPU cycles while checking condition what we are waiting for. So, instead we can just to tell the kernel to switch to another task, and wake up our task when waiting condition becomes true.
On Sat, Feb 20, 2010 at 1:02 AM, Greg Freemyer <[email protected]>wrote: > On Thu, Feb 18, 2010 at 4:39 PM, StephanT <[email protected]> > wrote: > > Hello all, > > > > Why would a linux driver call "schedule()" ? > > > > The LDD proposes this method to fight systems hangs caused by an infinite > > loop in the driver. In this > > case the "schedule()" call would be a workaround. I think better fix the > > infinite loop and abstain to call > > schedule()... > > > > I found more than 300 cases divers of the latest LK are calling schedule. > > Looks to me more like a > > necessity than a workaround. The following example is cut from > > "drivers/parport/parport_pc.c" > > > > if (need_resched() && > > time_before(jiffies, expire)) { > > schedule(); > > } > > > > The "need_resched()" call is a kernel inline function. Would this mean > that > > linux drivers should check > > this flag and graciously concede the CPU when asked for? > > > > Thanks sharing your opinion/knowledge on this, > > > > Stephan. > > > > LDD = Linux Device Drivers (book) > > LK = Linux Kernel. > > > > Stephan, > > I'm going to assume yours is basic question but there are also > sophisticated ways to answer. > > The tradition use of schedule is when a device driver is waiting for > hardware to do something. Remember lots of real world activity takes > milliseconds and a hard drive can take up to 30 seconds to time out. > > So if a driver is effectively idle because it is waiting for hardware, > but it has just been scheduled a time slice, the nice thing for the > driver to do is schedule another task if one is waiting for the CPU. > In fact the "kernel" is not interrupt-able in linux as I recall. Thus > a misbehaving driver that enters an infinite loop will hang the whole > machine. > > On a more sophisticated basis, you question can become "Why are device > drivers polling hardware when we have interrupts to keep that from > happening?" > > Damn good question and in general the polling mode is a fall-back mode > if there are issues with the interrupts or if you're working with > really low-end hardware. I think PIO mode for instance with IDE > drives was (and is) non-interrupt based and it is still supported as > the ultimate IDE fallback mode. > > Another way to ask your question is "Why isn't the linux kernel itself > timesliced?" > > I think that comes down to a complexity vs. functionality argument. > And I don't know enough to argue it one way or the other. > > HTH > Greg > > -- > To unsubscribe from this list: send an email with > "unsubscribe kernelnewbies" to [email protected] > Please read the FAQ at http://kernelnewbies.org/FAQ > > -- Regards, Denis
