A more general timeout specification

[ for comment only ]

The fusyn (robust mutexes) project proposes the creation of a more general data structure, 'struct timeout', for the specification of timeouts in new services. In this structure, the user specifies:

a time, in timespec format.
the clock the time is specified against (eg, CLOCK_MONOTONIC). whether the time is absolute, or relative to 'now'.

That is, all combinations of useful timeout attributes become possible.

Also proposed are two new kernel routines for the manipulation of timeouts:

timeout_validate()
timeout_sleep()

timeout_validate() error-checks the syntax of a timeout argument and returns either zero or -EINVAL. By breaking timeout_validate() out from timeout_sleep(), it becomes possible to error check the timeout 'far away' from the places in the code where we would actually do the timeout, as well as being able to perform such checks only at those places we know the timeout specification is coming from an unsafe source.

timeout_sleep() puts the caller to sleep until the specified end time is in the past, as measured against the given clock, or until the caller is awakened by other means (such as wake_up_process()). Like schedule_timeout(), TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE must be set ahead of time; if TASK_INTERRUPTIBLE is set then signals will also break the caller out of the sleep.

timeout_sleep() returns either 0 (returned early) or -ETIMEDOUT (returned due to timeout). It is up to the caller to resolve, in the "returned early" case, why it returned early.

Timeout_sleep has a return argument, endtime, which is also in 'struct timeout' format. If the input time was relative, then it is converted to absolute and returned through this argument. This can be used when an early-terminated service must be restarted and side effects of the early termination-n-restart (such as end time drift) are to be avoided.

Joe
"Money can buy bandwidth, but latency is forever" -- John Mashey

 2.6.12-rc4-jak/include/linux/time.h    |    6 +
 2.6.12-rc4-jak/include/linux/timeout.h |   48 ++++++++
 2.6.12-rc4-jak/kernel/posix-timers.c   |    7 +
 2.6.12-rc4-jak/kernel/timer.c          |  184 +++++++++++++++++++++++++++++++++
 4 files changed, 245 insertions(+)

diff -puNa include/linux/time.h~a.more.flexible.timeout.approach include/linux/time.h
@@ -25,6 +25,8 @@ struct timezone {
 	int	tz_dsttime;	/* type of dst correction */
 };
 
+#include <linux/timeout.h>
+
 #ifdef __KERNEL__
 
 /* Parameters used to convert the timespec values */

@@ -103,6 +105,10 @@ struct itimerval;
 extern int do_setitimer(int which, struct itimerval *value, struct itimerval *ovalue);
 extern int do_getitimer(int which, struct itimerval *value);
 extern void getnstimeofday (struct timespec *tv);
+extern long clock_gettime(int which, struct timespec *tp);
+
+extern int FASTCALL(abs_timespec_to_abs_jiffies (clockid_t clock, const struct timespec *tp, unsigned long *jp));
+extern int FASTCALL(rel_to_abs_timespec(clockid_t clock, const struct timespec *tsrel, struct timespec *tsabs));
 
 extern struct timespec timespec_trunc(struct timespec t, unsigned gran);
 

diff -puNa kernel/posix-timers.c~a.more.flexible.timeout.approach kernel/posix-timers.c
@@ -1288,6 +1288,13 @@ sys_clock_settime(clockid_t which_clock,
 	return CLOCK_DISPATCH(which_clock, clock_set, (which_clock, &new_tp));
 }
 
+long clock_gettime(clockid_t which_clock, struct timespec *tp)
+{
+	if (invalid_clockid(which_clock))
+		return -EINVAL;
+	return CLOCK_DISPATCH(which_clock, clock_get, (which_clock, tp));
+}
+
 asmlinkage long
 sys_clock_gettime(clockid_t which_clock, struct timespec __user *tp)
 {

_

...

The main reason why we are asking for this is that timeouts in POSIX calls are always specified in an absolute form. Because most system calls take it in a relative form, glibc has to call the kernel twice (one to get the time, one to do the syscall with the computed delta).

By having new syscalls that take advantage of this timeout interface, we can save this extra kernel call.

We believe it is generic enough for interfacing with user space timeouts, although we'd like to hear feedback :)

Inaky

Also, it is quite evil for a library to internally convert a user-specified end time into relative time .. this causes end-time drift.

Joe

If you do a new structure for this I would suggest adding a "precision" field (or the same with a different name). Basically precision would tell the kernel that the wakeup can be in a time range, not necessarily on the exact time specified. This helps optimizing the idle loop because you can batch timers better and is important for power management and virtualized environments. The kernel internally does not use support this yet, but there are plans to change the internal timers in this direction and if you're defining a new user interface I would add support for this.

I am not sure precision would be the right name, other suggestions are welcome.

It is also useful to avoid code duplication in compat.

-Andi

Very cool.
Joe

Andi Kleen wrote:
~>

I think the accepted and standard way to do this is to use different "clock"s. For example, in the HRT patch the clocks CLOCK_REALTIME_HR and CLOCK_MONOTONIC_HR are defined as high resolution clocks.

~

George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/

Andi, what is the kind of usage patterns you were envisioning? Do you know of anyone that would have kind of a hard requirement for doing it like you suggested?

George's argument makes sense to me, but I wonder if the audio people would have a rationale against it?

Inaky

Note precision here can be fairly long - some timers dont even if they run a minute earlier or later or even longer. For others it can be rather small.

I dont think you want own clocks for all possible numbers. It makes much more sense to give a numerical time offset.

-Andi

That may be, but you will have a hard time finding a standard confroming way to pass that info into the kernel. A few well chosen points should do it...

George Anzinger   [email protected]
High-res-timers:  http://sourceforge.net/projects/high-res-timers/

Hi John

Couple of months ago Joe Korty sent the attached proposal for a new interface and I was wondering if you could comment on it.

The main user of this new inteface is to allow system calls to get time specified in an absolute form (as most of POSIX states) and thus avoid extra time conversion work.

There was a short thread about it, available at google groups (grepping for the subject).

http://groups-beta.google.com/groups?q=a+more+general+timeout+specification

Thanks!

[ for comment only ]

The fusyn (robust mutexes) project proposes the creation of a more general data structure, 'struct timeout', for the specification of timeouts in new services. In this structure, the user specifies:

a time, in timespec format.
the clock the time is specified against (eg, CLOCK_MONOTONIC). whether the time is absolute, or relative to 'now'.

That is, all combinations of useful timeout attributes become possible.

Also proposed are two new kernel routines for the manipulation of timeouts:

timeout_validate()
timeout_sleep()

timeout_validate() error-checks the syntax of a timeout argument and returns either zero or -EINVAL. By breaking timeout_validate() out from timeout_sleep(), it becomes possible to error check the timeout 'far away' from the places in the code where we would actually do the timeout, as well as being able to perform such checks only at those places we know the timeout specification is coming from an unsafe source.

timeout_sleep() puts the caller to sleep until the specified end time is in the past, as measured against the given clock, or until the caller is awakened by other means (such as wake_up_process()). Like schedule_timeout(), TASK_INTERRUPTIBLE or TASK_UNINTERRUPTIBLE must be set ahead of time; if TASK_INTERRUPTIBLE is set then signals will also break the caller out of the sleep.

timeout_sleep() returns either 0 (returned early) or -ETIMEDOUT (returned due to timeout). It is up to the caller to resolve, in the "returned early" case, why it returned early.

Timeout_sleep has a return argument, endtime, which is also in 'struct timeout' format. If the input time was relative, then it is converted to absolute and returned through this argument. This can be used when an early-terminated service must be restarted and side effects of the early termination-n-restart (such as end time drift) are to be avoided.

Joe
"Money can buy bandwidth, but latency is forever" -- John Mashey

 2.6.12-rc4-jak/include/linux/time.h    |    6 +
 2.6.12-rc4-jak/include/linux/timeout.h |   48 ++++++++
 2.6.12-rc4-jak/kernel/posix-timers.c   |    7 +
 2.6.12-rc4-jak/kernel/timer.c          |  184 +++++++++++++++++++++++++++++++++
 4 files changed, 245 insertions(+)

diff -puNa include/linux/time.h~a.more.flexible.timeout.approach include/linux/time.h
@@ -25,6 +25,8 @@ struct timezone {
 	int	tz_dsttime;	/* type of dst correction */
 };
 
+#include <linux/timeout.h>
+
 #ifdef __KERNEL__
 
 /* Parameters used to convert the timespec values */

@@ -103,6 +105,10 @@ struct itimerval;
 extern int do_setitimer(int which, struct itimerval *value, struct itimerval *ovalue);
 extern int do_getitimer(int which, struct itimerval *value);
 extern void getnstimeofday (struct timespec *tv);
+extern long clock_gettime(int which, struct timespec *tp);
+
+extern int FASTCALL(abs_timespec_to_abs_jiffies (clockid_t clock, const struct timespec *tp, unsigned long *jp));
+extern int FASTCALL(rel_to_abs_timespec(clockid_t clock, const struct timespec *tsrel, struct timespec *tsabs));
 
 extern struct timespec timespec_trunc(struct timespec t, unsigned gran);
 

diff -puNa kernel/posix-timers.c~a.more.flexible.timeout.approach kernel/posix-timers.c
@@ -1288,6 +1288,13 @@ sys_clock_settime(clockid_t which_clock,
 	return CLOCK_DISPATCH(which_clock, clock_set, (which_clock, &new_tp));
 }
 
+long clock_gettime(clockid_t which_clock, struct timespec *tp)
+{
+	if (invalid_clockid(which_clock))
+		return -EINVAL;
+	return CLOCK_DISPATCH(which_clock, clock_get, (which_clock, tp));
+}
+
 asmlinkage long
 sys_clock_gettime(clockid_t which_clock, struct timespec __user *tp)
 {

Inaky

Hey Inaky, Joe,

Sorry for the terribly slow response. I haven't really dealt too much
with the user-space interfaces for the posix clocks and timers, so I'm no authority on it. Being able to use absolute values does seem very important to me, as well as avoiding having glibc make the conversion using gettimeofday() so that part looks good. I'm not completely sold on why the validate interface is needed, but I didn't hear any objections from George, so I'd defer to those who deal more with those interfaces.

Sorry for the lack of insight, although since I haven't heard much on this recently, maybe this will help stir up the debate?

Nish, do you have any comments on this idea?

thanks
-john