Re: Schedule() call in driver context.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Feb 18, 2010 at 4:39 PM, StephanT <stman937-linewbie@xxxxxxxxx> 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 ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ



[Index of Archives]     [Newbies FAQ]     [Linux Kernel Mentors]     [Linux Kernel Development]     [IETF Annouce]     [Git]     [Networking]     [Security]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux SCSI]     [Linux ACPI]
  Powered by Linux