[lkml]   [2005]   [Jun]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 04/12] block/xd: replace schedule_timeout() with msleep()
    On 21.06.2005 [17:43:53 +0100], Maciej W. Rozycki wrote:
    > On Tue, 21 Jun 2005, Nishanth Aravamudan wrote:
    > > schedule_timeout(1) is ambiguous in older/unchanged code since 2.4, as
    > > it indicated a 10 millisecond sleep then. Now, in 2.6, it indicates a 1
    > > millisecond sleep (HZ==1000). I am trying to prevent issues like this
    > > coming up in the future (CONFIG_HZ has hit -mm, e.g.) and msleep() is a
    > > good way to do so.
    > Well, HZ has never been consistent across platforms, e.g. 1024 for
    > the Alpha or even within certain platforms, e.g. 128 vs 100 for MIPS for
    > different configurations, so relying on jiffies to provide any absolute
    > time measurement has always been a misconception. But assuming all code
    > authors have failed to observe it is probably going a little bit too far,
    > so I'd always assume a given piece of code is correct unless I had reasons
    > to decide it does something silly.

    Right, I agree HZ is inconsistent. That is why I am trying to get users
    to use human-time interfaces, that way when HZ becomes dynamic (think
    tickless!) or variable at compile-time (already in -mm with efforts to
    get it merged to mainline via CONFIG_HZ). I know code authors have
    failed to observe the brokenness of ticks as time and am trying my
    hardest to fix up as many callers as possible. If nothing else, use


    I'm not saying your code is incorrect, by the way, I am just trying to
    make it maintainable and work on a kerneljanitor TODO.

    > > If you are trying to sleep for the shortest amount of time possible (a
    > > tick), though, then the code is fine, I guess. A comment may be useful,
    > > though.
    > This is obviously the case -- the code waits for a condition of an I/O
    > device to change and does not want to hog the CPU for the duration as the
    > device is slooow. I don't think any comment is needed -- it speaks for
    > itself: "I'm giving up now, but let me proceed at the next opportunity."

    Ok, there isn't much point in arguing this further then. My point was
    simply this: there is *a lot* of code that has not been updated since
    2.4 wrt. to sleep times. Thus, I cannot tell by reading the code,
    necessarily, whether a schedule_timeout(1) is referring to 1 millisecond
    or 1 tick. But that just may be me being confused.

    I appreciate all your feedback, Maciej.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-06-21 20:34    [W:0.024 / U:7.092 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site