Messages in this thread | | | Date | Tue, 14 Dec 2004 19:38:24 +0100 | From | Andrea Arcangeli <> | Subject | Re: dynamic-hz |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |