Re: Device driver

[Russell King - ARM Linux <linux@xxxxxxxxxxxxxxxx>]

On Sat, Mar 22, 2008 at 01:22:31PM +0100, Erazem wrote:
> Hello,
> Bill pointed out, that using "A sleep of '1' anything is usually
> problematic, because of how the 
> scheduler works". I try to find out more about this "problem", but no luck.
> Why is this problematic?

Firstly, all delays and sleeps are guaranteed to wait for at _least_ the
specified time.  In order to ensure that guarantee is kept, if we're
waiting for a one timer tick interval, we wait for _two_ timer ticks.

That means we guarantee that we slept for a period between one and two
ticks, rather than some period between zero and one (which would violate
our guarantee.)

The second thing to realise is that repeatedly doing a small amount of
work and then sleeping is probably not a good use of the CPU resources.
A better approach could be to set a timer to expire and use that to
change signal state, and when you've sent the entire byte of data, wake
up the process doing the write().

Finally, do you really need to wait 1ms, or would 100us or shorter do?
If yes, what about using udelay() instead of msleep()?  udelay() does
mean you're busy-waiting but if this is a rare event that might be
a better approach, especially if you can get the delay period lower.

-------------------------------------------------------------------
List admin: http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
FAQ:        http://www.arm.linux.org.uk/mailinglists/faq.php
Etiquette:  http://www.arm.linux.org.uk/mailinglists/etiquette.php