lkml.org 
[lkml]   [2008]   [May]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: better msleep for drivers
    Hi!

    >>>> Still longer term I suppose there's really no way around having accurate
    >>>> sleep functions and it's probably better to start testing earlier than later.
    >>> No objections, but we should not do that with a stupid msleep
    >>> replacement interface; instead we should expose a flexible in kernel
    >>> variant of hrtimer_nanosleep() which lets the user utilize
    >>> ABS/REL_TIME and the different clocks. A msleep helper can be built on
    >>> top of this very easily.
    >>
    >> While you are at it... it would be cool to have
    >>
    >> 'mdelay(2500 msec), but it is okay to wait 100msec more' -- type
    >> interface, so we could use that for nohz benefit.
    >>
    >> Currently, mdelay is 'it is okay to wait 10msec more' interface, and
    >> it would be nice to have that explicit.
    >
    > eh, I think you transposed mdelay with msleep?
    >
    > msleep() is the "it is okay to wait longer than I said" interface, not
    > mdelay(). mdelay() has always been non-sleeping and exact (as much as the
    > delay loop allows)

    Okay, I was a bit confused.

    Actually, both can delay for longer... msleep() in case of scheduling
    load, mdelay() in case of interrupt load...

    But the above was about hrtimer_nano*sleep*(), so that "how much
    latency we can tolarate" parameter would still be good.

    Pavel
    --
    (english) http://www.livejournal.com/~pavelmachek
    (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


    \
     
     \ /
      Last update: 2008-05-21 21:03    [W:0.020 / U:29.732 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site