Re: Linux nanosleep investigation.

[Andrea Arcangeli <andrea at suse dot de>]

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
things?

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
usleep.

>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
>standards.

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
you?

Andrea