Re: [RFC/PATCH] 2.6.24-rcx: Make sys_poll() wait at least timeout ms



Am Mittwoch, 19. Dezember 2007 schrieb Robert Han***:
Karsten Wiese wrote:
Am Mittwoch, 19. Dezember 2007 schrieb Robert Han***:
That seems fishy. What is your value of HZ and what is the timeout value
that was passed in the bad case?

HZ set to 250, timeout to 4ms.
Time spent in poll() taken by clock_gettime(CLOCK_MONOTONIC, &time)
before and after poll()call: i.e 62us.
Time measured with hpet gave 166us once.

msecs_to_jiffies (kernel/time.c) has this:

#if HZ <= MSEC_PER_SEC && !(MSEC_PER_SEC % HZ)
/*
* HZ is equal to or smaller than 1000, and 1000 is a nice
* round multiple of HZ, divide with the factor between them,
* but round upwards:
*/
return (m + (MSEC_PER_SEC / HZ) - 1) / (MSEC_PER_SEC / HZ);

With HZ=250 and m=4 this gives 7/4 or only 1 jiffy, which is not more
than 4ms, but if we are already at near the end of the current jiffy it
could be much less than that (potentially almost no time at all).

Maybe we could convert poll to use a hrtimer for this instead?

That wouldn't fix configs without hrtimers.

The linux manpage reflects current behaviour:
from man2/poll.2.gz
"The timeout argument specifies an upper limit on the time for which
poll() will block, in milliseconds."
To achieve "at least" timeouts we'd have to add a jiffy's ms to the
timeout in userspace.

I'd like to let sys_poll() behave according to posix's manpage:
from man3p/poll.3p.gz
"poll() shall wait at least timeout milliseconds"
Thats easier to specify in userspace. No need to know the running kernel's
HZ.

Above posix/linux difference also shows in select() manpages.
epoll_wait() (linux only) manpage also says "maximum time of timeout"
A more complete patch would tweek (p)poll (p)select and epoll_(p)wait.
There are possibly more syscalls affected that I'm not aware off.

Is there upstream interest?

Karsten
--
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/