Re: dynamic-hz

[Andrea Arcangeli]

On Tue, Dec 14, 2004 at 01:22:03PM -0500, linux-os wrote:
> Yield used to not show a spin in `top`.  Also, contrary to
> "popular" opinion, not all events are accompanied by interrupts.

Yes, ppa zip drive has the same issue.

yield shows a spin in top if it's the only running task. Otherwise it
will wait other task to run first. The behaviour has changed a bit
between 2.4 and 2.6, and we changed the corner cases. But the semantics
of yield are still the same.

> If they where, I'd gladly use one of the sleep_on* functions.

Minor detail: sleep_on is obsolete and should be deleted since it
requires the big kernel lock or the global cli to be safe. But I got the
point ;)

> For instance, I need to erase NVRAM (Flash). Then I need to
> program each byte. Waiting for the completion events requires
> polling the hardware. Proper software will give up the CPU
> while waiting and only sample the event, not continually spin.

This is a case where you know when you can expect the hardware to be
done (just like it was the case for the ppa zip). While dealing with
long hardware delays schedule_timeout makes plenty of sense. It would be
pointless to yield and spin, if you know nothing good can happen in the
next millisecond.

> The timeout of (0) was really to make the code more obvious, the
> facts being that we really need to get the CPU back as soon as
> there are no higher-priority tasks computable. If yield() would

With schedule_timeout(1) you're probably going to become interactive,
and you'll be scheduled before other tasks. That's good. I mean the
scheduler sorts things out automatically.

> work like schedule(0), of course I'd use it. The major problem
> with yield() probably has to do with accounting. The machine
> "feels" as though the CPU is properly available when you need
> it, however it appears to be spinning, using 100% system time.
> This makes customers nervous.

It's as well a waste of energy power to spin when you can
schedule_timeout(1).

So you're optimal at using schedule_timeout(1) in this case while
waiting hardware to complete as far as I can tell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/