* [RFC] A more general timeout specification
@ 2005-05-18 20:15 Joe Korty
2005-05-18 22:15 ` Inaky Perez-Gonzalez
` (2 more replies)
0 siblings, 3 replies; 12+ messages in thread
From: Joe Korty @ 2005-05-18 20:15 UTC (permalink / raw)
To: linux-kernel; +Cc: robustmutexes, george
[ 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
--- 2.6.12-rc4/include/linux/time.h~a.more.flexible.timeout.approach 2005-05-18 13:53:14.204417169 -0400
+++ 2.6.12-rc4-jak/include/linux/time.h 2005-05-18 13:53:14.212416002 -0400
@@ -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 /dev/null include/linux/timeout.h
--- /dev/null 2004-06-24 14:04:38.000000000 -0400
+++ 2.6.12-rc4-jak/include/linux/timeout.h 2005-05-18 13:53:14.212416002 -0400
@@ -0,0 +1,48 @@
+/*
+ * Extended timeout specification
+ *
+ * (C) 2002-2005 Intel Corp
+ * Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>.
+ *
+ * Licensed under the FSF's GNU Public License v2 or later.
+ *
+ * Generic extended timeout specification. Broken out by Joe Korty
+ * <joe.korty@ccur.com> from linux/time.h so that it can be included
+ * by userspace applications in conjunction with #include "time.h".
+ */
+
+#ifndef _LINUX_TIMEOUT_H
+#define _LINUX_TIMEOUT_H
+
+/* 'struct timeout' flag values. OR these into clock_id along with
+ * a clock specification such as CLOCK_REALTIME or CLOCK_MONOTONIC.
+ */
+enum {
+ TIMEOUT_RELATIVE = 0x10000000, /* relative timeout */
+
+ TIMEOUT_FLAGS_MASK = 0xf0000000, /* flags mask for clock_id */
+ TIMEOUT_CLOCK_MASK = 0x0fffffff, /* clock mask for clock_id */
+};
+
+/* Magic values a 'struct timeout' pointer can have */
+
+#define TIMEOUT_MAX ((struct timeout *) ~0UL) /* never time out */
+#define TIMEOUT_NONE ((struct timeout *) 0UL) /* time out immediately */
+
+/**
+ * struct timeout - general timeout specification
+ *
+ * @clock_id: which clock source to use ORed with flags describing use.
+ * @ts: timespec for the timeout
+ */
+struct timeout {
+ clockid_t clock_id;
+ struct timespec ts;
+};
+
+#ifdef __KERNEL__
+extern int FASTCALL(timeout_validate (const struct timeout *));
+extern int FASTCALL(timeout_sleep (const struct timeout *, struct timeout *));
+#endif
+
+#endif
diff -puNa kernel/posix-timers.c~a.more.flexible.timeout.approach kernel/posix-timers.c
--- 2.6.12-rc4/kernel/posix-timers.c~a.more.flexible.timeout.approach 2005-05-18 13:53:14.207416731 -0400
+++ 2.6.12-rc4-jak/kernel/posix-timers.c 2005-05-18 13:53:14.214415710 -0400
@@ -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)
{
diff -puNa kernel/timer.c~a.more.flexible.timeout.approach kernel/timer.c
--- 2.6.12-rc4/kernel/timer.c~a.more.flexible.timeout.approach 2005-05-18 13:53:14.209416440 -0400
+++ 2.6.12-rc4-jak/kernel/timer.c 2005-05-18 15:27:06.363710594 -0400
@@ -1129,6 +1129,190 @@ fastcall signed long __sched schedule_ti
EXPORT_SYMBOL(schedule_timeout);
+/**
+ * timeout_validate - verify that a timeout specification is self-consistant.
+ * @tp - pointer to the 'struct timeout' to verify
+ * @returns - 0 if no error, <0 errno code if there was
+ */
+fastcall int timeout_validate(const struct timeout *tp)
+{
+ int result;
+ unsigned flags, clock_id;
+
+ result = 0;
+ if (tp == TIMEOUT_MAX || tp == TIMEOUT_NONE)
+ goto out;
+
+ flags = tp->clock_id & TIMEOUT_FLAGS_MASK;
+ clock_id = tp->clock_id & TIMEOUT_CLOCK_MASK;
+
+ result = -EINVAL;
+ if (flags & ~TIMEOUT_RELATIVE)
+ goto out;
+
+ /* someday, we should support *all* clocks available to us */
+ if (clock_id != CLOCK_REALTIME && clock_id != CLOCK_MONOTONIC)
+ goto out;
+ if ((unsigned long)tp->ts.tv_nsec >= NSEC_PER_SEC)
+ goto out;
+ result = 0;
+out:
+ return result;
+}
+EXPORT_SYMBOL_GPL(timeout_validate);
+
+/** rel_to_abs_timespec - convert a relative timespec into an absolute timespec
+ * @clock - the system clock the timespecs are specified in.
+ * @tsrel - a pointer to the relative timespec to be converted.
+ * @tsabs - a pointer to where the absolute timespec is to be stored.
+ * @returns - 0 if converted, <0 if error.
+ */
+fastcall int rel_to_abs_timespec(clockid_t clock, const struct timespec *tsrel,
+ struct timespec *tsabs)
+{
+ int result;
+ struct timespec now;
+
+ result = clock_gettime(clock, &now);
+ if (result >= 0) {
+ set_normalized_timespec(tsabs, now.tv_sec + tsrel->tv_sec,
+ now.tv_nsec + tsrel->tv_nsec);
+ }
+ return result;
+}
+EXPORT_SYMBOL_GPL(rel_to_abs_timespec);
+
+/**
+ * abs_timespec_to_abs_jiffies - convert an absolute timespec into
+ * absolute jiffies.
+ *
+ * @clock - select which clock @tp is specified against. CLOCK_MONOTONIC and
+ * CLOCK_REALTIME are two possibilities.
+ * @tp - absolute timespec that is to be converted to jiffies.
+ * @jp - absolute jiffies returned through this pointer.
+ * @returns - 0 if converted, <0 if error.
+ */
+fastcall int abs_timespec_to_abs_jiffies (clockid_t clock,
+ const struct timespec *tp, unsigned long *jp)
+{
+ int result;
+ unsigned long jiffies_abs, seq;
+ struct timespec oc, now;
+
+ do {
+ seq = read_seqbegin(&xtime_lock);
+ result = clock_gettime(clock, &now);
+ if (result < 0)
+ return result;
+ jiffies_abs = jiffies;
+ } while (read_seqretry(&xtime_lock, seq));
+
+ set_normalized_timespec(&oc, tp->tv_sec - now.tv_sec,
+ tp->tv_nsec - now.tv_nsec);
+
+ if (oc.tv_sec > 0 || (oc.tv_sec == 0 && oc.tv_nsec > 0))
+ jiffies_abs += timespec_to_jiffies(&oc) + 1;
+ *jp = jiffies_abs;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(abs_timespec_to_abs_jiffies);
+
+/* Helper function. Handles the proper setting of @endtime when
+ * an @endtime needs to be returned. Returns an approximation for
+ * the ending time in jiffies. The approximation is guaranteed to
+ * be on or just past the true ending time.
+ */
+static inline
+unsigned long __timeout_sleep_timespec (const struct timeout *timeout,
+ struct timeout *endtime)
+{
+ unsigned long jiffies_abs;
+ struct timespec end;
+ clockid_t clock_id = timeout->clock_id & TIMEOUT_CLOCK_MASK;
+
+ if (timeout->clock_id & TIMEOUT_RELATIVE) {
+ rel_to_abs_timespec(clock_id, &timeout->ts, &end);
+ if (endtime) {
+ endtime->clock_id = clock_id;
+ endtime->ts = end;
+ }
+ }
+ else
+ end = timeout->ts;
+
+ abs_timespec_to_abs_jiffies(clock_id, &end, &jiffies_abs);
+ return jiffies_abs;
+}
+
+/**
+ * timeout_sleep - sleep until woken up, interrupted, or the
+ * designated wakeup time is past.
+ * @timeout:
+ * time to wait. const struct timeout pointer. May take
+ * on the special values TIMEOUT_MAX (never time out) or
+ * TIMEOUT_NONE (times out instantly). @timeout must be
+ * error-checked by timeout_validate() beforehand.
+ * @endtime:
+ * time remaining. A 'struct timeout' value, holding the
+ * end time of the period in absolute format and specified
+ * against the same clock that @timeout was specified against,
+ * is returned through this pointer. No value is returned
+ * if @endtime is NULL, if @timeout is TIMEOUT_MAX or
+ * TIMEOUT_NONE, or if @timeout is itself specified in
+ * absolute time.
+ * @returns:
+ * -ETIMEDOUT if awakened due to timeout, 0 otherwise.
+ */
+fastcall int timeout_sleep (const struct timeout *timeout, struct timeout *endtime)
+{
+ unsigned long jiffies_endtime;
+ struct timer_list timer;
+ int result;
+
+ if (timeout == TIMEOUT_NONE)
+ goto simulate_timeout;
+
+ if (timeout == TIMEOUT_MAX)
+ goto never_timeout;
+
+ if (timeout->ts.tv_sec == MAX_SCHEDULE_TIMEOUT)
+ goto never_timeout;
+
+ jiffies_endtime = __timeout_sleep_timespec(timeout, endtime);
+
+ if (time_after_eq(jiffies, jiffies_endtime))
+ goto simulate_timeout;
+
+ init_timer(&timer);
+ timer.expires = jiffies_endtime;
+ timer.data = (unsigned long)current;
+ timer.function = process_timeout;
+ add_timer(&timer);
+ schedule();
+ result = -ETIMEDOUT;
+ if (del_singleshot_timer_sync (&timer))
+ result = 0;
+ goto out;
+
+ /*
+ * simulate a timeout without actually expiring a timer
+ */
+simulate_timeout:
+ process_timeout((unsigned long)current);
+ result = -ETIMEDOUT;
+ goto out;
+
+ /*
+ * Sleep without a timeout scheduled.
+ */
+never_timeout:
+ schedule();
+ result = 0;
+out:
+ return result;
+}
+EXPORT_SYMBOL_GPL (timeout_sleep);
+
/* Thread ID - the internal kernel "pid" */
asmlinkage long sys_gettid(void)
{
_
^ permalink raw reply [flat|nested] 12+ messages in thread
* [RFC] A more general timeout specification
2005-05-18 20:15 [RFC] A more general timeout specification Joe Korty
@ 2005-05-18 22:15 ` Inaky Perez-Gonzalez
2005-05-19 13:39 ` Joe Korty
2005-05-18 23:49 ` Andi Kleen
2005-07-29 1:52 ` FW: " Inaky Perez-Gonzalez
2 siblings, 1 reply; 12+ messages in thread
From: Inaky Perez-Gonzalez @ 2005-05-18 22:15 UTC (permalink / raw)
To: linux-kernel; +Cc: joe.korty, robustmutexes, george
>>>>> Joe Korty <joe.korty@ccur.com> writes:
> [ 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.
...
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC] A more general timeout specification
2005-05-18 20:15 [RFC] A more general timeout specification Joe Korty
2005-05-18 22:15 ` Inaky Perez-Gonzalez
@ 2005-05-18 23:49 ` Andi Kleen
2005-05-19 13:24 ` Joe Korty
2005-05-19 17:02 ` George Anzinger
2005-07-29 1:52 ` FW: " Inaky Perez-Gonzalez
2 siblings, 2 replies; 12+ messages in thread
From: Andi Kleen @ 2005-05-18 23:49 UTC (permalink / raw)
To: joe.korty; +Cc: robustmutexes, george, linux-kernel
Joe Korty <joe.korty@ccur.com> writes:
> 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'.
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.
> 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
It is also useful to avoid code duplication in compat.
-Andi
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC] A more general timeout specification
2005-05-18 23:49 ` Andi Kleen
@ 2005-05-19 13:24 ` Joe Korty
2005-05-19 17:02 ` George Anzinger
1 sibling, 0 replies; 12+ messages in thread
From: Joe Korty @ 2005-05-19 13:24 UTC (permalink / raw)
To: Andi Kleen; +Cc: robustmutexes, george, linux-kernel
On Thu, May 19, 2005 at 01:49:11AM +0200, Andi Kleen wrote:
> Joe Korty <joe.korty@ccur.com> writes:
>
> > 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'.
>
> 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.
Very cool.
Joe
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC] A more general timeout specification
2005-05-18 22:15 ` Inaky Perez-Gonzalez
@ 2005-05-19 13:39 ` Joe Korty
0 siblings, 0 replies; 12+ messages in thread
From: Joe Korty @ 2005-05-19 13:39 UTC (permalink / raw)
To: Inaky Perez-Gonzalez; +Cc: linux-kernel, robustmutexes, george
On Wed, May 18, 2005 at 03:15:54PM -0700, Inaky Perez-Gonzalez wrote:
> 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
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC] A more general timeout specification
2005-05-18 23:49 ` Andi Kleen
2005-05-19 13:24 ` Joe Korty
@ 2005-05-19 17:02 ` George Anzinger
2005-05-19 18:35 ` Inaky Perez-Gonzalez
2005-05-20 19:05 ` Andi Kleen
1 sibling, 2 replies; 12+ messages in thread
From: George Anzinger @ 2005-05-19 17:02 UTC (permalink / raw)
To: Andi Kleen; +Cc: joe.korty, robustmutexes, linux-kernel
Andi Kleen wrote:
~>
>
> 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.
>
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 george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC] A more general timeout specification
2005-05-19 17:02 ` George Anzinger
@ 2005-05-19 18:35 ` Inaky Perez-Gonzalez
2005-05-20 19:05 ` Andi Kleen
1 sibling, 0 replies; 12+ messages in thread
From: Inaky Perez-Gonzalez @ 2005-05-19 18:35 UTC (permalink / raw)
To: Andi Kleen; +Cc: george, joe.korty, robustmutexes, linux-kernel
> George Anzinger <george@mvista.com> writes:
>> Andi Kleen wrote: ~>
>> If you do a new structure for this I would suggest adding a
>> "precision" field (or the same with a different name). Basically
>> ....
> 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.
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC] A more general timeout specification
2005-05-19 17:02 ` George Anzinger
2005-05-19 18:35 ` Inaky Perez-Gonzalez
@ 2005-05-20 19:05 ` Andi Kleen
2005-05-21 1:12 ` George Anzinger
1 sibling, 1 reply; 12+ messages in thread
From: Andi Kleen @ 2005-05-20 19:05 UTC (permalink / raw)
To: George Anzinger; +Cc: joe.korty, robustmutexes, linux-kernel
> 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.
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC] A more general timeout specification
2005-05-20 19:05 ` Andi Kleen
@ 2005-05-21 1:12 ` George Anzinger
0 siblings, 0 replies; 12+ messages in thread
From: George Anzinger @ 2005-05-21 1:12 UTC (permalink / raw)
To: Andi Kleen; +Cc: joe.korty, robustmutexes, linux-kernel
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.
>
>
> 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.
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 george@mvista.com
High-res-timers: http://sourceforge.net/projects/high-res-timers/
^ permalink raw reply [flat|nested] 12+ messages in thread
* FW: [RFC] A more general timeout specification
2005-05-18 20:15 [RFC] A more general timeout specification Joe Korty
2005-05-18 22:15 ` Inaky Perez-Gonzalez
2005-05-18 23:49 ` Andi Kleen
@ 2005-07-29 1:52 ` Inaky Perez-Gonzalez
2005-08-22 22:56 ` john stultz
2 siblings, 1 reply; 12+ messages in thread
From: Inaky Perez-Gonzalez @ 2005-07-29 1:52 UTC (permalink / raw)
To: johnstul; +Cc: joe.korty, george, inaky.perez-gonzalez, linux-kernel
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
--- 2.6.12-rc4/include/linux/time.h~a.more.flexible.timeout.approach 2005-05-18 13:53:14.204417169 -0400
+++ 2.6.12-rc4-jak/include/linux/time.h 2005-05-18 13:53:14.212416002 -0400
@@ -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 /dev/null include/linux/timeout.h
--- /dev/null 2004-06-24 14:04:38.000000000 -0400
+++ 2.6.12-rc4-jak/include/linux/timeout.h 2005-05-18 13:53:14.212416002 -0400
@@ -0,0 +1,48 @@
+/*
+ * Extended timeout specification
+ *
+ * (C) 2002-2005 Intel Corp
+ * Inaky Perez-Gonzalez <inaky.perez-gonzalez@intel.com>.
+ *
+ * Licensed under the FSF's GNU Public License v2 or later.
+ *
+ * Generic extended timeout specification. Broken out by Joe Korty
+ * <joe.korty@ccur.com> from linux/time.h so that it can be included
+ * by userspace applications in conjunction with #include "time.h".
+ */
+
+#ifndef _LINUX_TIMEOUT_H
+#define _LINUX_TIMEOUT_H
+
+/* 'struct timeout' flag values. OR these into clock_id along with
+ * a clock specification such as CLOCK_REALTIME or CLOCK_MONOTONIC.
+ */
+enum {
+ TIMEOUT_RELATIVE = 0x10000000, /* relative timeout */
+
+ TIMEOUT_FLAGS_MASK = 0xf0000000, /* flags mask for clock_id */
+ TIMEOUT_CLOCK_MASK = 0x0fffffff, /* clock mask for clock_id */
+};
+
+/* Magic values a 'struct timeout' pointer can have */
+
+#define TIMEOUT_MAX ((struct timeout *) ~0UL) /* never time out */
+#define TIMEOUT_NONE ((struct timeout *) 0UL) /* time out immediately */
+
+/**
+ * struct timeout - general timeout specification
+ *
+ * @clock_id: which clock source to use ORed with flags describing use.
+ * @ts: timespec for the timeout
+ */
+struct timeout {
+ clockid_t clock_id;
+ struct timespec ts;
+};
+
+#ifdef __KERNEL__
+extern int FASTCALL(timeout_validate (const struct timeout *));
+extern int FASTCALL(timeout_sleep (const struct timeout *, struct timeout *));
+#endif
+
+#endif
diff -puNa kernel/posix-timers.c~a.more.flexible.timeout.approach kernel/posix-timers.c
--- 2.6.12-rc4/kernel/posix-timers.c~a.more.flexible.timeout.approach 2005-05-18 13:53:14.207416731 -0400
+++ 2.6.12-rc4-jak/kernel/posix-timers.c 2005-05-18 13:53:14.214415710 -0400
@@ -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)
{
diff -puNa kernel/timer.c~a.more.flexible.timeout.approach kernel/timer.c
--- 2.6.12-rc4/kernel/timer.c~a.more.flexible.timeout.approach 2005-05-18 13:53:14.209416440 -0400
+++ 2.6.12-rc4-jak/kernel/timer.c 2005-05-18 15:27:06.363710594 -0400
@@ -1129,6 +1129,190 @@ fastcall signed long __sched schedule_ti
EXPORT_SYMBOL(schedule_timeout);
+/**
+ * timeout_validate - verify that a timeout specification is self-consistant.
+ * @tp - pointer to the 'struct timeout' to verify
+ * @returns - 0 if no error, <0 errno code if there was
+ */
+fastcall int timeout_validate(const struct timeout *tp)
+{
+ int result;
+ unsigned flags, clock_id;
+
+ result = 0;
+ if (tp == TIMEOUT_MAX || tp == TIMEOUT_NONE)
+ goto out;
+
+ flags = tp->clock_id & TIMEOUT_FLAGS_MASK;
+ clock_id = tp->clock_id & TIMEOUT_CLOCK_MASK;
+
+ result = -EINVAL;
+ if (flags & ~TIMEOUT_RELATIVE)
+ goto out;
+
+ /* someday, we should support *all* clocks available to us */
+ if (clock_id != CLOCK_REALTIME && clock_id != CLOCK_MONOTONIC)
+ goto out;
+ if ((unsigned long)tp->ts.tv_nsec >= NSEC_PER_SEC)
+ goto out;
+ result = 0;
+out:
+ return result;
+}
+EXPORT_SYMBOL_GPL(timeout_validate);
+
+/** rel_to_abs_timespec - convert a relative timespec into an absolute timespec
+ * @clock - the system clock the timespecs are specified in.
+ * @tsrel - a pointer to the relative timespec to be converted.
+ * @tsabs - a pointer to where the absolute timespec is to be stored.
+ * @returns - 0 if converted, <0 if error.
+ */
+fastcall int rel_to_abs_timespec(clockid_t clock, const struct timespec *tsrel,
+ struct timespec *tsabs)
+{
+ int result;
+ struct timespec now;
+
+ result = clock_gettime(clock, &now);
+ if (result >= 0) {
+ set_normalized_timespec(tsabs, now.tv_sec + tsrel->tv_sec,
+ now.tv_nsec + tsrel->tv_nsec);
+ }
+ return result;
+}
+EXPORT_SYMBOL_GPL(rel_to_abs_timespec);
+
+/**
+ * abs_timespec_to_abs_jiffies - convert an absolute timespec into
+ * absolute jiffies.
+ *
+ * @clock - select which clock @tp is specified against. CLOCK_MONOTONIC and
+ * CLOCK_REALTIME are two possibilities.
+ * @tp - absolute timespec that is to be converted to jiffies.
+ * @jp - absolute jiffies returned through this pointer.
+ * @returns - 0 if converted, <0 if error.
+ */
+fastcall int abs_timespec_to_abs_jiffies (clockid_t clock,
+ const struct timespec *tp, unsigned long *jp)
+{
+ int result;
+ unsigned long jiffies_abs, seq;
+ struct timespec oc, now;
+
+ do {
+ seq = read_seqbegin(&xtime_lock);
+ result = clock_gettime(clock, &now);
+ if (result < 0)
+ return result;
+ jiffies_abs = jiffies;
+ } while (read_seqretry(&xtime_lock, seq));
+
+ set_normalized_timespec(&oc, tp->tv_sec - now.tv_sec,
+ tp->tv_nsec - now.tv_nsec);
+
+ if (oc.tv_sec > 0 || (oc.tv_sec == 0 && oc.tv_nsec > 0))
+ jiffies_abs += timespec_to_jiffies(&oc) + 1;
+ *jp = jiffies_abs;
+ return 0;
+}
+EXPORT_SYMBOL_GPL(abs_timespec_to_abs_jiffies);
+
+/* Helper function. Handles the proper setting of @endtime when
+ * an @endtime needs to be returned. Returns an approximation for
+ * the ending time in jiffies. The approximation is guaranteed to
+ * be on or just past the true ending time.
+ */
+static inline
+unsigned long __timeout_sleep_timespec (const struct timeout *timeout,
+ struct timeout *endtime)
+{
+ unsigned long jiffies_abs;
+ struct timespec end;
+ clockid_t clock_id = timeout->clock_id & TIMEOUT_CLOCK_MASK;
+
+ if (timeout->clock_id & TIMEOUT_RELATIVE) {
+ rel_to_abs_timespec(clock_id, &timeout->ts, &end);
+ if (endtime) {
+ endtime->clock_id = clock_id;
+ endtime->ts = end;
+ }
+ }
+ else
+ end = timeout->ts;
+
+ abs_timespec_to_abs_jiffies(clock_id, &end, &jiffies_abs);
+ return jiffies_abs;
+}
+
+/**
+ * timeout_sleep - sleep until woken up, interrupted, or the
+ * designated wakeup time is past.
+ * @timeout:
+ * time to wait. const struct timeout pointer. May take
+ * on the special values TIMEOUT_MAX (never time out) or
+ * TIMEOUT_NONE (times out instantly). @timeout must be
+ * error-checked by timeout_validate() beforehand.
+ * @endtime:
+ * time remaining. A 'struct timeout' value, holding the
+ * end time of the period in absolute format and specified
+ * against the same clock that @timeout was specified against,
+ * is returned through this pointer. No value is returned
+ * if @endtime is NULL, if @timeout is TIMEOUT_MAX or
+ * TIMEOUT_NONE, or if @timeout is itself specified in
+ * absolute time.
+ * @returns:
+ * -ETIMEDOUT if awakened due to timeout, 0 otherwise.
+ */
+fastcall int timeout_sleep (const struct timeout *timeout, struct timeout *endtime)
+{
+ unsigned long jiffies_endtime;
+ struct timer_list timer;
+ int result;
+
+ if (timeout == TIMEOUT_NONE)
+ goto simulate_timeout;
+
+ if (timeout == TIMEOUT_MAX)
+ goto never_timeout;
+
+ if (timeout->ts.tv_sec == MAX_SCHEDULE_TIMEOUT)
+ goto never_timeout;
+
+ jiffies_endtime = __timeout_sleep_timespec(timeout, endtime);
+
+ if (time_after_eq(jiffies, jiffies_endtime))
+ goto simulate_timeout;
+
+ init_timer(&timer);
+ timer.expires = jiffies_endtime;
+ timer.data = (unsigned long)current;
+ timer.function = process_timeout;
+ add_timer(&timer);
+ schedule();
+ result = -ETIMEDOUT;
+ if (del_singleshot_timer_sync (&timer))
+ result = 0;
+ goto out;
+
+ /*
+ * simulate a timeout without actually expiring a timer
+ */
+simulate_timeout:
+ process_timeout((unsigned long)current);
+ result = -ETIMEDOUT;
+ goto out;
+
+ /*
+ * Sleep without a timeout scheduled.
+ */
+never_timeout:
+ schedule();
+ result = 0;
+out:
+ return result;
+}
+EXPORT_SYMBOL_GPL (timeout_sleep);
+
/* Thread ID - the internal kernel "pid" */
asmlinkage long sys_gettid(void)
{
--
Inaky
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: FW: [RFC] A more general timeout specification
2005-07-29 1:52 ` FW: " Inaky Perez-Gonzalez
@ 2005-08-22 22:56 ` john stultz
0 siblings, 0 replies; 12+ messages in thread
From: john stultz @ 2005-08-22 22:56 UTC (permalink / raw)
To: Inaky Perez-Gonzalez
Cc: Nishanth Aravamudan, joe.korty, george, inaky.perez-gonzalez,
linux-kernel
On Thu, 2005-07-28 at 18:52 -0700, Inaky Perez-Gonzalez wrote:
> 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.
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
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [RFC] A more general timeout specification
2005-09-01 15:18 ` Roman Zippel
@ 2005-09-01 21:20 ` Kyle Moffett
0 siblings, 0 replies; 12+ messages in thread
From: Kyle Moffett @ 2005-09-01 21:20 UTC (permalink / raw)
To: Roman Zippel
Cc: Joe Korty, Perez-Gonzalez, Inaky, akpm, george, johnstul,
linux-kernel
On Sep 1, 2005, at 11:18:52, Roman Zippel wrote:
> On Thu, 1 Sep 2005, Joe Korty wrote:
>> On Thu, Sep 01, 2005 at 11:19:51AM +0200, Roman Zippel wrote:
>>> You still didn't explain what's the point in choosing
>>> different clock sources for a _timeout_.
>>
>> Well, if CLOCK_REALTIME is set forward by a minute,
>> timers & timeout specified against that clock will expire
>> a minute earlier than expected.
>
> That just rather suggests that the pthread API is broken as usual.
> (No other possible user was mentioned so far.)
How about a hypothetical time-based event daemon. I want to run
some jobs every 10 minutes that the system is running (not off or
suspended), I want to run other jobs every hour in real time, and
if one such timer expires while suspended, I want to run it
immediately to catch up. The first suggests CLOCK_MONOTONIC, and
the second works better with CLOCK_REALTIME.
> So in practice it's easier to advance CLOCK_MONOTONIC/CLOCK_REALTIME
> equally and only apply time jumps to CLOCK_REALTIME.
I thought that's what he said, but maybe I'm just confused :-D.
Cheers,
Kyle Moffett
--
Premature optimization is the root of all evil in programming
-- C.A.R. Hoare
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2005-09-01 21:21 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-05-18 20:15 [RFC] A more general timeout specification Joe Korty
2005-05-18 22:15 ` Inaky Perez-Gonzalez
2005-05-19 13:39 ` Joe Korty
2005-05-18 23:49 ` Andi Kleen
2005-05-19 13:24 ` Joe Korty
2005-05-19 17:02 ` George Anzinger
2005-05-19 18:35 ` Inaky Perez-Gonzalez
2005-05-20 19:05 ` Andi Kleen
2005-05-21 1:12 ` George Anzinger
2005-07-29 1:52 ` FW: " Inaky Perez-Gonzalez
2005-08-22 22:56 ` john stultz
-- strict thread matches above, loose matches on Subject: below --
2005-09-01 0:00 Perez-Gonzalez, Inaky
2005-09-01 9:19 ` Roman Zippel
2005-09-01 13:48 ` Joe Korty
2005-09-01 15:18 ` Roman Zippel
2005-09-01 21:20 ` Kyle Moffett
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox