Re: Schedule() call in driver context.

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

 



Hi Stephan...

Just sharing my humble thoughts...

On Fri, Feb 19, 2010 at 4:39 AM, StephanT <stman937-linewbie@xxxxxxxxx> wrote:
> Hello all,
>
> Why would a linux driver call "schedule()" ?

Basically, to relinquish a certain kernel code path and to switch to
the other one (be it user mode or kernel mode).

And as to "why would kernel developers do so?" IMO to optimize
throuhgput...that is the number of jobs of done during certain time
interval.

> 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?

I think this code is written to make sure that if other code path is
asking for rescheduling, then it is done at the earliest moment
possible. Even if kernel is compiled with full kernel preemption
style, it would just mean the rescheduling is done in nearest tick.
And that could mean long enough.

This is not something like "you must do this" rule IMO. You are free
not to put such codes and simply do busy wait. However, ask
yourself... do you really need such tight loop? Are you going to poll
something that is time sensitive? If yes, then maybe you won't need to
call schedule() at all....but again, do it very carefully so that bugs
won't lock up your system.

PS: Uhm, maybe kernel hacking thingies like "soft lockup warning" and
"NMI watch dog" could help to tackle this lock up situation...should
that happen I think.

-- 
regards,

Mulyadi Santosa
Freelance Linux trainer and consultant

blog: the-hydra.blogspot.com
training: mulyaditraining.blogspot.com

--
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