lkml.org 
[lkml]   [2004]   [Dec]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: dynamic-hz
    On Tue, 14 Dec 2004, Andrea Arcangeli wrote:

    > On Tue, Dec 14, 2004 at 08:54:29AM -0800, Nish Aravamudan wrote:
    >> Hmm, schedule_timeout(0) working that way is interesting. There is
    >> also the option to use schedule_timeout(MAX_SCHEDULE_TIMEOUT) which
    >> should sleep indefinitely (depending of course on the conditions of
    >> the state). Oh but I think I understand what you're saying... the
    >> driver needs to sleep indefinitely in total (potentially), but needs
    >> to be able to return quite often (like yield() used to) so they could
    >> check a condition...
    >>
    >> Thanks for the input!
    >
    > what do you mean like yield() used to? yield() is still there in latest
    > 2.6, just call yield() and you'll get the same effect of sched_yield in
    > userspace. yields in the kernel are a bad thing though (they usually
    > mean code is not well written, code should be event driven not polled
    > driven).
    >

    Yield used to not show a spin in `top`. Also, contrary to
    "popular" opinion, not all events are accompanied by interrupts.
    If they where, I'd gladly use one of the sleep_on* functions.

    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.

    You can get away with software murder if you only need to program
    something that saves some state between shutdowns. However, if
    you have a writable flash file-system you need to do it right.

    > Note that __set_current_state(..); schedule_timeout(0) is not like
    > yield. yield will return immediatly if it's the only task running. A
    > yielding loop will consume all available cpu, while the
    > schedule_timeout(0) will wait less than 1/HZ sec. But really

    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
    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.

    > schedule_timeout(0) makes little sense, either use schedule_timeout(1)
    > and explicitly wait 1msec, or use yield. schedule_timeout(0) just
    > happens to work because the timer code has to approximate for excess and
    > it will wait for the next timer irq for timeouts <= 0 and it will wait
    > for two ticks for timeouts == 1 etc...
    >
    > I guess we could change schedule_timeout() to WARN_ON if 0 is being
    > passed to it.
    >

    Cheers,
    Dick Johnson
    Penguin : Linux version 2.6.9 on an i686 machine (5537.79 BogoMips).
    Notice : All mail here is now cached for review by John Ashcroft.
    98.36% of all statistics are fiction.
    -
    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/

    \
     
     \ /
      Last update: 2005-03-22 14:08    [W:2.955 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site