Linux-kernel mailing list archive 1999-34,: Re: How to wait while polling

# Re: How to wait while polling

Ken Pizzini (ken@halcyon.com)
Sun, 22 Aug 1999 21:22:15 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Mike Galbraith: "Re: Linux 2.2.12pre, raid-0.90"
- Previous message: CaT: "Re: Very slow IDE performance"

On linux-kernel
message <Pine.PMDF.3.96.990822142935.49005A-100000@ic3.ithaca.edu>,
<kbaker3@ic3.ithaca.edu> wrote:

> How do I wait in a
>multitasking friendly method?

Use schedule_timout(). Parameter is the number of ticks (1/HZ
second intervals) before you wish to be given control again.

>while ((count<3000) and (data!=BUSY)){
>parport_read_status(parport,data);
>}
>
>but that is really nasty obviously. From looking around I have seen
>udelay() and mdelay() whats the diff and how do I use them.

udelay() takes a microsecond argument, mdelay() takes a
millisecond argument. udelay() operates in a tight loop,
and so is quite multitasking-hostile for large delays (but
essential for small delays). mdelay() actually calls udelay()
in its own loop, because udelay() might fail due to overflowing
its counter on very fast machines; thus it too is not friendly
to other tasks wishing to run.

> I think I need around 1/200th of a second delay

How precisely? And how bad is it if the delay is a bit off (in
each direction)?

Since HZ is only 100 on most systems, schedule_timeout() won't
quite get you where you want to be --- you can either
schedule_timeout(HZ/100), which probably delays too long (0.01 s,
typically), or schedule_timeout(HZ/200), which probably doesn't
delay long enough (~0 s typical, though it does allow other tasks
to be scheduled before returning control to your driver).

Basically your choices for a 1/200 s delay are to hog the CPU
and be precise with mdelay(5), or to be generous to other tasks
but sloppy in your delay with schedule_timeout(0) (and a
(limited) retry loop, since if you are the only runnable task
you will regain the CPU quite rapidly).

--Ken Pizzini

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/

- Next message: Mike Galbraith: "Re: Linux 2.2.12pre, raid-0.90"
- Previous message: CaT: "Re: Very slow IDE performance"