ltp nanosleep02 test
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): 1060095904.28044.105.camel@plars
Quoted 17 lines · Paul Larson
Quoted 4 lines · Andrew Morton
OK, thanks.
Paul, if nanosleep2 is really dead then you should bury it and stop scaring people ;)
Actually this test will pass just fine if you increase
USEC_PRECISIONto something more reasonable than 100. However it looks like whoever wrote this test made it intentionally low. This is the comment right before the #defineUSEC_PRECISION100:
/*
* Define here the "rem" precision in microseconds,
* Various implementations will provide different
* precisions. The -aa tree provides up to usec precision.
* NOTE: all the trees that don't provide a precision of
* the order of the microseconds are subject to an userspace
Quoted 8 lines
* live lock condition with glibc under a flood of signals,
* the "rem" field would never change without the increased
* usec precision in the -aa tree.
*/
So does anyone know if this patch from the -aa tree is reasonable or has a chance of making it into the mainline kernel? Does this livelock situation still exist or was it solved by other means? If this is no longer a potential problem then I will gladly remove the test.
I haven't seen the patch :( There is a little misdirection in that comment, however. The kernel rounds up the time to the nearest resolution and then adds that resolution (resolution is 1/HZ, by the way). The round up is required by the standard as is the add. The add is to make sure the expiry time is AFTER and never before the requested time.
What is passed back as the remaining time is the true remaining time after this calculation.
The live lock would occur if the caller then used that time to sleep again (i.e. to complete the sleep) as the kernel would again add the 1/HZ to the given value. So each signal, the time would be extended by a jiffie.
The best way to solve this is to use the absolute time version of clock_nanosleep, but, sigh, that means a change in glibc.
Signature · 3 lines
George Anzinger [email protected] High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml