Re: [patch] sys_epoll_wait() timeout saga ...

[Willy Tarreau]

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.

Regards,
Willy

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/