[RFC] Driver writer's guide to sleeping

[RFC] Driver writer's guide to sleeping

[Denis Vlasenko]

Hi folks,

I'm working on a Linux wireless driver.

I compiled a little guide for myself about waiting primitives.
I would appreciate if you look thru it. Maybe I'm wrong somewhere.

udelay(us)
	Busywaits for specified amount of usecs.
	Ok to call in IRQ-disabled regions.
	May be preempted (if not in atomic region).
    Q: how precise is it? (can it sometimes wait much longer?
    If yes, is that happens only if preempted?)

mdelay(ms)
	Same as udelay but for msecs.

schedule()
	switch to other runnable task, if any. CPU
	will be returned to us as soon as no other runnable tasks
	with higher dynamic prio are left. This means
	that sometimes schedule() returns practically at once.

yield()
	like schedule() but also drop our dynamic prio
	to the minimum. result: all other runnable tasks will
	run before CPU is returned to us. Yet, yield may return
	at once if there is no runnable tasks.

schedule_timeout(timeout)
	Whee, it has a comment! :)
 * %TASK_UNINTERRUPTIBLE - at least @timeout jiffies are guaranteed to
 * pass before the routine returns. The routine will return 0
 *
 * %TASK_INTERRUPTIBLE - the routine may return early if a signal is
 * delivered to the current task. In this case the remaining time
 * in jiffies will be returned, or 0 if the timer expired in time
 *
 * The current task state is guaranteed to be TASK_RUNNING when this
 * routine returns.
	Thus:
	set_current_state(TASK_[UN]INTERRUPTIBLE);
	schedule_timeout(timeout_in_jiffies)

msleep(ms)
	Sleeps at least ms msecs.
	Equivalent to:
	set_current_state(TASK_UNINTERRUPTIBLE);
	schedule_timeout(timeout)
    Q: why implementation does while(timeout) timeout = schedule_timeout(timeout)?
    Does that mean that	schedule_timeout's comment (see above) is not true?!

msleep_interruptible(ms)
	Sleeps ms msecs (or more) unless has been woken up (signal, waitqueue...).
    Q: exact list of possible waking events? (I'm a bit overwhelmed by multitude
    of slightly different waitqueues, tasklets, softirqs, bhs...)

ssleep(s)
	Same as msleep but in seconds

need_resched()
	returns true if for some reason kernel would like to schedule
	another task. Useful to check under lock for lock breaking.

cond_resched()
	basically: while(need_resched()) schedule();
	returns 1 if scheduled at least once.
--
vda

Re: [RFC] Driver writer's guide to sleeping

[Oliver Neukum]

On Sat, 25 Jun 2005, Denis Vlasenko wrote:

> schedule_timeout(timeout)
> 	Whee, it has a comment! :)
>  * %TASK_UNINTERRUPTIBLE - at least @timeout jiffies are guaranteed to
>  * pass before the routine returns. The routine will return 0
>  *
>  * %TASK_INTERRUPTIBLE - the routine may return early if a signal is
>  * delivered to the current task. In this case the remaining time
>  * in jiffies will be returned, or 0 if the timer expired in time
>  *
>  * The current task state is guaranteed to be TASK_RUNNING when this
>  * routine returns.
> 	Thus:
> 	set_current_state(TASK_[UN]INTERRUPTIBLE);
> 	schedule_timeout(timeout_in_jiffies)
> 
> msleep(ms)
> 	Sleeps at least ms msecs.
> 	Equivalent to:
> 	set_current_state(TASK_UNINTERRUPTIBLE);
> 	schedule_timeout(timeout)

If and only if you are not on any waitqueue. You may not be interrupted
by a signal, but you still can be woken with an explicit wake_up()

	HTH
		Oliver

Re: [RFC] Driver writer's guide to sleeping

[Denis Vlasenko]

On Saturday 25 June 2005 14:29, Oliver Neukum wrote:
> On Sat, 25 Jun 2005, Denis Vlasenko wrote:
> 
> > schedule_timeout(timeout)
> > 	Whee, it has a comment! :)
> >  * %TASK_UNINTERRUPTIBLE - at least @timeout jiffies are guaranteed to
> >  * pass before the routine returns. The routine will return 0
[snip]
> > 	Thus:
> > 	set_current_state(TASK_[UN]INTERRUPTIBLE);
> > 	schedule_timeout(timeout_in_jiffies)
> > 
> > msleep(ms)
> > 	Sleeps at least ms msecs.
> > 	Equivalent to:
> > 	set_current_state(TASK_UNINTERRUPTIBLE);
> > 	schedule_timeout(timeout)
> 
> If and only if you are not on any waitqueue. You may not be interrupted
> by a signal, but you still can be woken with an explicit wake_up()

Like this?
--
vda

--- linux-2.6.12.src/kernel/timer.c.orig	Sun Jun 19 16:11:00 2005
+++ linux-2.6.12.src/kernel/timer.c	Sat Jun 25 14:50:22 2005
@@ -1059,12 +1059,16 @@ static void process_timeout(unsigned lon
  *
  * You can set the task state as follows -
  *
- * %TASK_UNINTERRUPTIBLE - at least @timeout jiffies are guaranteed to
- * pass before the routine returns. The routine will return 0
+ * %TASK_UNINTERRUPTIBLE - at least @timeout jiffies will pass
+ * before the routine returns, unless something explicitly
+ * wakes you up with wake_up_process(). Signals won't interrupt
+ * such sleep.
  *
  * %TASK_INTERRUPTIBLE - the routine may return early if a signal is
- * delivered to the current task. In this case the remaining time
- * in jiffies will be returned, or 0 if the timer expired in time
+ * delivered to the current task.
+ *
+ * The remaining time in jiffies will be returned, or 0 if the timer
+ * expired in time.
  *
  * The current task state is guaranteed to be TASK_RUNNING when this
  * routine returns.

Re: [RFC] Driver writer's guide to sleeping

[Oliver Neukum]

Am Samstag, 25. Juni 2005 13:54 schrieb Denis Vlasenko:
> On Saturday 25 June 2005 14:29, Oliver Neukum wrote:
> > On Sat, 25 Jun 2005, Denis Vlasenko wrote:
> > 
> > > schedule_timeout(timeout)
> > > 	Whee, it has a comment! :)
> > >  * %TASK_UNINTERRUPTIBLE - at least @timeout jiffies are guaranteed to
> > >  * pass before the routine returns. The routine will return 0
> [snip]
> > > 	Thus:
> > > 	set_current_state(TASK_[UN]INTERRUPTIBLE);
> > > 	schedule_timeout(timeout_in_jiffies)
> > > 
> > > msleep(ms)
> > > 	Sleeps at least ms msecs.
> > > 	Equivalent to:
> > > 	set_current_state(TASK_UNINTERRUPTIBLE);
> > > 	schedule_timeout(timeout)
> > 
> > If and only if you are not on any waitqueue. You may not be interrupted
> > by a signal, but you still can be woken with an explicit wake_up()
> 
> Like this?

Yes, but we have macros for that. You are supposed to use them.

	Regards
		Oliver

Re: [RFC] Driver writer's guide to sleeping

[Denis Vlasenko]

On Sunday 26 June 2005 22:38, Oliver Neukum wrote:
> Am Samstag, 25. Juni 2005 13:54 schrieb Denis Vlasenko:
> > On Saturday 25 June 2005 14:29, Oliver Neukum wrote:
> > > On Sat, 25 Jun 2005, Denis Vlasenko wrote:
> > > 
> > > > schedule_timeout(timeout)
> > > > 	Whee, it has a comment! :)
> > > >  * %TASK_UNINTERRUPTIBLE - at least @timeout jiffies are guaranteed to
> > > >  * pass before the routine returns. The routine will return 0
> > [snip]
> > > > 	Thus:
> > > > 	set_current_state(TASK_[UN]INTERRUPTIBLE);
> > > > 	schedule_timeout(timeout_in_jiffies)
> > > > 
> > > > msleep(ms)
> > > > 	Sleeps at least ms msecs.
> > > > 	Equivalent to:
> > > > 	set_current_state(TASK_UNINTERRUPTIBLE);
> > > > 	schedule_timeout(timeout)
> > > 
> > > If and only if you are not on any waitqueue. You may not be interrupted
> > > by a signal, but you still can be woken with an explicit wake_up()
> > 
> > Like this?
> 
> Yes, but we have macros for that. You are supposed to use them.

Erm.. I meant "Shall we correct that comment then, like this?".
Comment is plain wrong now.
--
vda

Re: [RFC] Driver writer's guide to sleeping

[Domen Puncer]

On 25/06/05 12:50 +0300, Denis Vlasenko wrote:
> Hi folks,
> 
...
> msleep_interruptible(ms)
> 	Sleeps ms msecs (or more) unless has been woken up (signal, waitqueue...).
>     Q: exact list of possible waking events? (I'm a bit overwhelmed by multitude
>     of slightly different waitqueues, tasklets, softirqs, bhs...)

Only signal (or, obviously, timeout) will wake it. wake_up*() will not.

Re: [RFC] Driver writer's guide to sleeping

[Nish Aravamudan]

On 6/25/05, Denis Vlasenko <vda@ilport.com.ua> wrote:
> Hi folks,
> 
> I'm working on a Linux wireless driver.
> 
> I compiled a little guide for myself about waiting primitives.
> I would appreciate if you look thru it. Maybe I'm wrong somewhere.

<snip>
> schedule_timeout(timeout)
<snip>
> msleep(ms)
<snip>
> msleep_interruptible(ms)
<snip>

So, there are four cases in the schedule_timeout() family of sleeps,
based one what you would like to be woken up on:

Signals and Waitqueue events:
     set_current_state(TASK_INTERRUPTIBLE);
     schedule_timeout(some_time_in_jiffies);

Signals only:
     msleep_interruptible(some_time_in_msecs);

Waitqueue events only:
      set_current_state(TASK_UNINTERRUPTIBLE);
      schedule_timeout(some_time_in_jiffies);

Neither signals nor waitqueues:
      msleep(some_time_in_msecs);

Hopefully that clears some things up.

w.r.t to wait-queue event sleeping, you probably should also be aware
of the wait_event() family of macros.

Thanks,
Nish