[lkml]   [2005]   [Sep]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch] sys_epoll_wait() timeout saga ...
    On Sat, Sep 24, 2005 at 08:10:32AM -0700, Davide Libenzi wrote:
    > >+ jtimeout = timeout < 0 || \
    > >+ timeout >= (1000ULL * MAX_SCHEDULE_TIMEOUT / HZ) ||
    > >\
    > >+ timeout >= (LONG_MAX / HZ - 1000) ?
    > > MAX_SCHEDULE_TIMEOUT: (timeout * HZ + 999) / 1000;
    > >
    > >as both are constants, they can be optimized. Otherwise, we can resort to
    > >using a MAX() macro to reduce this to only one test which will catch all
    > >corner cases.
    > Using the MIN() macro would be better so we have a single check, and the
    > compiler optimize that automatically.

    you're right, it's MIN() not MAX() ;-)
    Anyway, I've checked the code and the compiler does a single test with -O2.

    > Or we can force 'timeout * HZ' to use ULL math. I don't think it makes a lot of difference for something that is in a likely sleep path ;)

    "likely", yes, but not necessarily. Under a high load, you can have enough
    events queued so that epoll() will not wait at all. I've already encountered
    such cases during benchmarks, and I noticed that epoll() took more time than
    select() for small numbers of FDs (something like 20% below 100 FDs), but of
    course, it is considerably faster above. So turning the multiply to an ULL
    may increase this overhead on some architectures, while the double check
    will leave the code identical.


    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-09-24 19:26    [W:0.020 / U:11.524 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site