This is the mail archive of the
mailing list for the glibc project.
Re: Linux nanosleep investigation.
- To: Kaz Kylheku <kaz at ashi dot footprints dot net>
- Subject: Re: Linux nanosleep investigation.
- From: Andrea Arcangeli <andrea at suse dot de>
- Date: Wed, 16 Feb 2000 01:25:25 +0100 (CET)
- cc: Andreas Jaeger <aj at suse dot de>, "Kevin B. Hendricks" <khendricks at ivey dot uwo dot ca>, Ulrich Drepper <drepper at cygnus dot com>, libc-alpha Mailinglist <libc-alpha at sourceware dot cygnus dot com>
On Tue, 15 Feb 2000, Kaz Kylheku wrote:
>In the last hours? I went to ftp.ca.linux.org, and the file has a Feb 15 1999
>date on this server! That confused me for a few seconds.
I developed it on Feb 15 1999 infact. Maybe you got confused by timezones
This is the date of my email:
Date: Tue, 15 Feb 2000 23:11:11 +0100 (CET)
This is the date of the file in my local hd that is the source for the
kernel.org ftp area:
andrea@alpha:~/kernel/kernel.org/patches/v2.2/2.2.14 > ls -l nanosleep-1.gz
-rw-r--r-- 1 andrea andrea 1295 Feb 15 18:37 nanosleep-1.gz
And these are the dates of the modifyed files:
andrea@alpha:~/kernel/kernel.org/patches/v2.2/2.2.14 > zcat nanosleep-1.gz | grep +++
+++ 2.2.14-nanosleep/arch/alpha/kernel/time.c Tue Feb 15 18:30:42 2000
+++ 2.2.14-nanosleep/arch/i386/kernel/time.c Tue Feb 15 18:31:00 2000
+++ 2.2.14-nanosleep/include/linux/time.h Tue Feb 15 18:34:03 2000
+++ 2.2.14-nanosleep/kernel/sched.c Tue Feb 15 18:09:16 2000
What's wrong? :)
>There is one remaining unsolvable issue. The expiry time is still adjusted up
>by one jiffy if the wait is non-zero (and larger than the threshold for doing a
>CPU delay fine wait):
> expire = timespec_to_jiffies(&t) + (t.tv_sec || t.tv_nsec);
You can't have more resolution than one jiffy anyway unless you accept to
>This *cannot* be fixed in the kernel. Because the Single UNIX Specification,
I have not changed anything in the sleep time.
>and I assume POSIX as well, clearly state that the nanosleep function must not
>wake up until the specified time has passed. The wait can be rounded up, but
>not down! Breaking this would break nanosleep's compliance with the applicable
I haven't broken that with my patch as far I can tell.
>Until we get such a call, what we could do is compensate by fudging the input
>timespec value. For example, if the timespec is greater than or equal to one
>jiffy, LinuxThreads could decrease it by one jiffy.
I think one possible way to be more precise in nanosleep for RT tasks
could be to not add the additional jiffy to the schedule_timeout call, and
then to usleep for the remaining time if no signal happened meanwhile (we
now know the remaining time with my patch doing after-before). Looks
doable in my way. Anyway I don't think that would be that useful (sure it
won't be useful to non RT users). If you want to sleep longer than 10 msec
you don't care to wakeup 5msec after as far I can tell. Could you explain
me exactly why the 5msec of additional sleep will make a difference for