* Re: Periodic posix timer support broke between 2.6.9-rc1 and
@ 2004-10-13 16:03 Christoph Lameter
2004-10-13 17:25 ` Periodic posix timer support broke between 2.6.9-rc1 and 2.6.9-rc1-bk17 George Anzinger
2004-10-13 17:29 ` Periodic posix timer support broke between 2.6.9-rc1 and Christoph Lameter
0 siblings, 2 replies; 7+ messages in thread
From: Christoph Lameter @ 2004-10-13 16:03 UTC (permalink / raw)
To: linux-ia64
On Tue, 12 Oct 2004, George Anzinger wrote:
> Christoph Lameter wrote:
> > I ran some test programs and discovered that the periodic timer support
> > is broken. The timer is triggered once and then never again. Single shot
> > timers work fine. 2.6.9-rc1 is fine. The first kernel that I tested where
> > I noticed the breakage was 2.6.9-rc1-bk17. 2.6.9-rc2 and following all
> > cannot do periodic timer signals.
> >
> > I looked through the changelog but I cannot see anything that would cause
> > the problem. Roland's patch surely could not have done this.
> >
> > Will try to track this down further, time permitting...
>
> The most likely thing would be failure to do the call back from the signal
> delivery code.
The problem is IA64 arch specific. Works fine on i386.
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Periodic posix timer support broke between 2.6.9-rc1 and 2.6.9-rc1-bk17 2004-10-13 16:03 Periodic posix timer support broke between 2.6.9-rc1 and Christoph Lameter @ 2004-10-13 17:25 ` George Anzinger 2004-10-13 17:29 ` Periodic posix timer support broke between 2.6.9-rc1 and Christoph Lameter 1 sibling, 0 replies; 7+ messages in thread From: George Anzinger @ 2004-10-13 17:25 UTC (permalink / raw) To: linux-ia64 Christoph Lameter wrote: > On Tue, 12 Oct 2004, George Anzinger wrote: > > >>Christoph Lameter wrote: >> >>>I ran some test programs and discovered that the periodic timer support >>>is broken. The timer is triggered once and then never again. Single shot >>>timers work fine. 2.6.9-rc1 is fine. The first kernel that I tested where >>>I noticed the breakage was 2.6.9-rc1-bk17. 2.6.9-rc2 and following all >>>cannot do periodic timer signals. >>> >>>I looked through the changelog but I cannot see anything that would cause >>>the problem. Roland's patch surely could not have done this. >>> >>>Will try to track this down further, time permitting... >> >>The most likely thing would be failure to do the call back from the signal >>delivery code. > > > The problem is IA64 arch specific. Works fine on i386. And I repeat: The most likely thing would be failure to do the call back from the signal delivery code. > -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Periodic posix timer support broke between 2.6.9-rc1 and 2004-10-13 16:03 Periodic posix timer support broke between 2.6.9-rc1 and Christoph Lameter 2004-10-13 17:25 ` Periodic posix timer support broke between 2.6.9-rc1 and 2.6.9-rc1-bk17 George Anzinger @ 2004-10-13 17:29 ` Christoph Lameter 1 sibling, 0 replies; 7+ messages in thread From: Christoph Lameter @ 2004-10-13 17:29 UTC (permalink / raw) To: linux-ia64 On Wed, 13 Oct 2004, George Anzinger wrote: > The most likely thing would be failure to do the call back from the signal > delivery code. The problem was my setting of the resolution of CLOCK_REALTIME and CLOCK_MONOTONIC to the resolution of the time interpolator. That screwed up interval calculation. Fix was submitted to Andrew and Linus and will hopefully get into 2.6.9 final. ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <B6E8046E1E28D34EB815A11AC8CA312902CD3264@mtv-atc-605e--n.corp.sgi.com>]
* Re: [time] add support for CLOCK_THREAD_CPUTIME_ID and CLOCK_PROCESS_CPUTIME_ID [not found] <B6E8046E1E28D34EB815A11AC8CA312902CD3264@mtv-atc-605e--n.corp.sgi.com> @ 2004-09-24 12:16 ` Christoph Lameter 2004-09-25 4:25 ` Ulrich Drepper 0 siblings, 1 reply; 7+ messages in thread From: Christoph Lameter @ 2004-09-24 12:16 UTC (permalink / raw) To: linux-kernel Hmm .... some further refinement to properly handle the process clock. The new thread groups make that possible ... Index: linus/kernel/posix-timers.c =================================================================== --- linus.orig/kernel/posix-timers.c 2004-09-23 15:12:01.000000000 -0700 +++ linus/kernel/posix-timers.c 2004-09-24 05:07:42.000000000 -0700 @@ -133,18 +133,10 @@ * resolution. Here we define the standard CLOCK_REALTIME as a * 1/HZ resolution clock. * - * CPUTIME & THREAD_CPUTIME: We are not, at this time, definding these - * two clocks (and the other process related clocks (Std - * 1003.1d-1999). The way these should be supported, we think, - * is to use large negative numbers for the two clocks that are - * pinned to the executing process and to use -pid for clocks - * pinned to particular pids. Calls which supported these clock - * ids would split early in the function. - * * RESOLUTION: Clock resolution is used to round up timer and interval * times, NOT to report clock times, which are reported with as * much resolution as the system can muster. In some cases this - * resolution may depend on the underlaying clock hardware and + * resolution may depend on the underlying clock hardware and * may not be quantifiable until run time, and only then is the * necessary code is written. The standard says we should say * something about this issue in the documentation... @@ -162,7 +154,7 @@ * * At this time all functions EXCEPT clock_nanosleep can be * redirected by the CLOCKS structure. Clock_nanosleep is in - * there, but the code ignors it. + * there, but the code ignores it. * * Permissions: It is assumed that the clock_settime() function defined * for each clock will take care of permission checks. Some @@ -198,6 +190,8 @@ struct timespec *tp, struct timespec *mo); int do_posix_clock_monotonic_gettime(struct timespec *tp); int do_posix_clock_monotonic_settime(struct timespec *tp); +int do_posix_clock_process_gettime(struct timespec *tp); +int do_posix_clock_thread_gettime(struct timespec *tp); static struct k_itimer *lock_timer(timer_t timer_id, unsigned long *flags); static inline void unlock_timer(struct k_itimer *timr, unsigned long flags) @@ -218,6 +212,14 @@ .clock_get = do_posix_clock_monotonic_gettime, .clock_set = do_posix_clock_monotonic_settime }; + struct k_clock clock_thread = {.res = CLOCK_REALTIME_RES, + .abs_struct = NULL, + .clock_get = do_posix_clock_thread_gettime + }; + struct k_clock clock_process = {.res = CLOCK_REALTIME_RES, + .abs_struct = NULL, + .clock_get = do_posix_clock_process_gettime + }; #ifdef CONFIG_TIME_INTERPOLATION /* Clocks are more accurate with time interpolators */ @@ -226,6 +228,8 @@ register_posix_clock(CLOCK_REALTIME, &clock_realtime); register_posix_clock(CLOCK_MONOTONIC, &clock_monotonic); + register_posix_clock(CLOCK_PROCESS_CPUTIME_ID, &clock_process); + register_posix_clock(CLOCK_THREAD_CPUTIME_ID, &clock_thread); posix_timers_cache = kmem_cache_create("posix_timers_cache", sizeof (struct k_itimer), 0, 0, NULL, NULL); @@ -1227,6 +1231,18 @@ return -EINVAL; } +int do_posix_clock_thread_gettime(struct timespec *tp) +{ + jiffies_to_timespec(get_jiffies_64()-current->start_time, tp); + return 0; +} + +int do_posix_clock_process_gettime(struct timespec *tp) +{ + jiffies_to_timespec(get_jiffies_64()-current->group_leader->start_time, tp); + return 0; +} + asmlinkage long sys_clock_settime(clockid_t which_clock, const struct timespec __user *tp) { ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [time] add support for CLOCK_THREAD_CPUTIME_ID and CLOCK_PROCESS_CPUTIME_ID 2004-09-24 12:16 ` [time] add support for CLOCK_THREAD_CPUTIME_ID and CLOCK_PROCESS_CPUTIME_ID Christoph Lameter @ 2004-09-25 4:25 ` Ulrich Drepper 2004-09-25 5:54 ` Christoph Lameter 0 siblings, 1 reply; 7+ messages in thread From: Ulrich Drepper @ 2004-09-25 4:25 UTC (permalink / raw) To: Christoph Lameter; +Cc: linux-kernel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christoph Lameter wrote: > +int do_posix_clock_thread_gettime(struct timespec *tp) > +{ > + jiffies_to_timespec(get_jiffies_64()-current->start_time, tp); > + return 0; > +} > + > +int do_posix_clock_process_gettime(struct timespec *tp) > +{ > + jiffies_to_timespec(get_jiffies_64()-current->group_leader->start_time, tp); > + return 0; > +} > + This is pretty useless. Why would you need kernel support for this, it just measures realtime. We have an implementation of the CPU time in glibc which can easily be changed to support clocks of this precision if there are no usable timestamp counters (which is what is currently used). And all this is not really what was really meant by "CPU time" in the POSIX spec. We hijacked this symbol, maybe incorrectly so. What is really meant is how much time a process/thread actually _uses_ the CPU (hence the name). I.e., the information contained in struct rusage. For this I would love to get kernel support and we hopefully have soon a patch for this. - -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBVPNJ2ijCOnn/RHQRAjXeAJ0dUlvRmh6eDJLD6BtmjI3CNWC7pQCfZvAG wSJclC6wagAwrYqL7/rdpVs= =SLxp -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [time] add support for CLOCK_THREAD_CPUTIME_ID and CLOCK_PROCESS_CPUTIME_ID 2004-09-25 4:25 ` Ulrich Drepper @ 2004-09-25 5:54 ` Christoph Lameter 2004-09-25 6:08 ` Ulrich Drepper 0 siblings, 1 reply; 7+ messages in thread From: Christoph Lameter @ 2004-09-25 5:54 UTC (permalink / raw) To: Ulrich Drepper; +Cc: linux-kernel On Fri, 24 Sep 2004, Ulrich Drepper wrote: > For this I would love to get kernel support and we hopefully have soon a > patch for this. Then please sign off on the following patch: Index: linus/kernel/posix-timers.c =================================================================== --- linus.orig/kernel/posix-timers.c 2004-09-23 15:12:01.000000000 -0700 +++ linus/kernel/posix-timers.c 2004-09-24 22:51:51.000000000 -0700 @@ -133,18 +133,10 @@ * resolution. Here we define the standard CLOCK_REALTIME as a * 1/HZ resolution clock. * - * CPUTIME & THREAD_CPUTIME: We are not, at this time, definding these - * two clocks (and the other process related clocks (Std - * 1003.1d-1999). The way these should be supported, we think, - * is to use large negative numbers for the two clocks that are - * pinned to the executing process and to use -pid for clocks - * pinned to particular pids. Calls which supported these clock - * ids would split early in the function. - * * RESOLUTION: Clock resolution is used to round up timer and interval * times, NOT to report clock times, which are reported with as * much resolution as the system can muster. In some cases this - * resolution may depend on the underlaying clock hardware and + * resolution may depend on the underlying clock hardware and * may not be quantifiable until run time, and only then is the * necessary code is written. The standard says we should say * something about this issue in the documentation... @@ -162,7 +154,7 @@ * * At this time all functions EXCEPT clock_nanosleep can be * redirected by the CLOCKS structure. Clock_nanosleep is in - * there, but the code ignors it. + * there, but the code ignores it. * * Permissions: It is assumed that the clock_settime() function defined * for each clock will take care of permission checks. Some @@ -198,6 +190,8 @@ struct timespec *tp, struct timespec *mo); int do_posix_clock_monotonic_gettime(struct timespec *tp); int do_posix_clock_monotonic_settime(struct timespec *tp); +int do_posix_clock_process_gettime(struct timespec *tp); +int do_posix_clock_thread_gettime(struct timespec *tp); static struct k_itimer *lock_timer(timer_t timer_id, unsigned long *flags); static inline void unlock_timer(struct k_itimer *timr, unsigned long flags) @@ -218,6 +212,14 @@ .clock_get = do_posix_clock_monotonic_gettime, .clock_set = do_posix_clock_monotonic_settime }; + struct k_clock clock_thread = {.res = CLOCK_REALTIME_RES, + .abs_struct = NULL, + .clock_get = do_posix_clock_thread_gettime + }; + struct k_clock clock_process = {.res = CLOCK_REALTIME_RES, + .abs_struct = NULL, + .clock_get = do_posix_clock_process_gettime + }; #ifdef CONFIG_TIME_INTERPOLATION /* Clocks are more accurate with time interpolators */ @@ -226,6 +228,8 @@ register_posix_clock(CLOCK_REALTIME, &clock_realtime); register_posix_clock(CLOCK_MONOTONIC, &clock_monotonic); + register_posix_clock(CLOCK_PROCESS_CPUTIME_ID, &clock_process); + register_posix_clock(CLOCK_THREAD_CPUTIME_ID, &clock_thread); posix_timers_cache = kmem_cache_create("posix_timers_cache", sizeof (struct k_itimer), 0, 0, NULL, NULL); @@ -1227,6 +1231,19 @@ return -EINVAL; } +int do_posix_clock_thread_gettime(struct timespec *tp) +{ + jiffies_to_timespec(current->signal->cutime + current->signal->cstime, tp); + return 0; +} + +int do_posix_clock_process_gettime(struct timespec *tp) +{ + jiffies_to_timespec(current->group_leader->signal->cutime + + current->group_leader->signal->cstime, tp); + return 0; +} + asmlinkage long sys_clock_settime(clockid_t which_clock, const struct timespec __user *tp) { ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [time] add support for CLOCK_THREAD_CPUTIME_ID and CLOCK_PROCESS_CPUTIME_ID 2004-09-25 5:54 ` Christoph Lameter @ 2004-09-25 6:08 ` Ulrich Drepper [not found] ` <B6E8046E1E28D34EB815A11AC8CA312902CD327E@mtv-atc-605e--n.corp.sgi.com> 0 siblings, 1 reply; 7+ messages in thread From: Ulrich Drepper @ 2004-09-25 6:08 UTC (permalink / raw) To: Christoph Lameter; +Cc: linux-kernel -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Christoph Lameter wrote: > Then please sign off on the following patch: Sorry, I fail to see the point. The CPUTIME stuff will either way be entire implemented at userlevel. If we use TSC, we compute the resolution from the CPU clock speed (no need to comment, I know it's not reliable everywhere). If we fall back on realtime, we will simply in glibc map clock_getres (CLOCK_PROCESS_CPUTIME_ID, &ts) to clock_getres (CLOCK_REALTIME, &ts) The kernel knows nothing about this clock. The comment changes are OK, of course. If there is more to change this is in glibc. So far I have not heard of anybody wanting to use the clocks this way. This is why we do not have the fallback to realtime implemented. If you say you need it I have no problem adding appropriate patches. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBVQt32ijCOnn/RHQRAsWHAJ9q1Aztzf7/6TYQbu6X+DNQhFFW5wCfTP57 wbjQQe+iV/s1ODANFFYK+zs= =JVgJ -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <B6E8046E1E28D34EB815A11AC8CA312902CD327E@mtv-atc-605e--n.corp.sgi.com>]
* [RFC] Posix compliant behavior of CLOCK_PROCESS/THREAD_CPUTIME_ID [not found] ` <B6E8046E1E28D34EB815A11AC8CA312902CD327E@mtv-atc-605e--n.corp.sgi.com> @ 2004-09-27 20:58 ` Christoph Lameter 2004-09-28 19:18 ` Ulrich Drepper 0 siblings, 1 reply; 7+ messages in thread From: Christoph Lameter @ 2004-09-27 20:58 UTC (permalink / raw) To: Ulrich Drepper; +Cc: johnstul, Ulrich.Windl, george, linux-kernel, libc-alpha Attached follows a patch to implement the POSIX clocks according to the POSIX standard which states in V3 of the Single Unix Specification: 1. CLOCK_PROCESS_CPUTIME_ID Implementations shall also support the special clockid_t value CLOCK_PROCESS_CPUTIME_ID, which represents the CPU-time clock of the calling process when invoking one of the clock_*() or timer_*() functions. For these clock IDs, the values returned by clock_gettime() and specified by clock_settime() represent the amount of execution time of the process associated with the clock. 2. CLOCK_THREAD_CPUTIME_ID Implementations shall also support the special clockid_t value CLOCK_THREAD_CPUTIME_ID, which represents the CPU-time clock of the calling thread when invoking one of the clock_*() or timer_*() functions. For these clock IDs, the values returned by clock_gettime() and specified by clock_settime() shall represent the amount of execution time of the thread associated with the clock. These times mentioned are CPU processing times and not the time that has passed since the startup of a process. Glibc currently provides its own implementation of these two clocks which is designed to return the time that passed since the startup of a process or a thread. Moreover this clock is bound to CPU timers which is problematic when the frequency of the clock changes or the process is moved to a different processor whose cpu timer may not be fully synchronized to the cpu timer of the current CPU. I would like to have the following patch integrated into the kernel. Glibc would need to be modified to simply generate a system call for clock_* without doing its own emulation of a clock. CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME id were never intended to be used as a means to access a time stamp counter on a CPU and it may be better to find another means of accesses the cpu time registerss. The patch is really quite straighforward and only affects one file... Index: linus/kernel/posix-timers.c =================================================================== --- linus.orig/kernel/posix-timers.c 2004-09-23 15:12:01.000000000 -0700 +++ linus/kernel/posix-timers.c 2004-09-27 13:42:40.000000000 -0700 @@ -10,6 +10,10 @@ * 2004-06-01 Fix CLOCK_REALTIME clock/timer TIMER_ABSTIME bug. * Copyright (C) 2004 Boris Hu * + * 2004-07-27 Provide POSIX compliant clocks + * CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID. + * by Christoph Lameter + * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or (at @@ -133,18 +137,10 @@ * resolution. Here we define the standard CLOCK_REALTIME as a * 1/HZ resolution clock. * - * CPUTIME & THREAD_CPUTIME: We are not, at this time, definding these - * two clocks (and the other process related clocks (Std - * 1003.1d-1999). The way these should be supported, we think, - * is to use large negative numbers for the two clocks that are - * pinned to the executing process and to use -pid for clocks - * pinned to particular pids. Calls which supported these clock - * ids would split early in the function. - * * RESOLUTION: Clock resolution is used to round up timer and interval * times, NOT to report clock times, which are reported with as * much resolution as the system can muster. In some cases this - * resolution may depend on the underlaying clock hardware and + * resolution may depend on the underlying clock hardware and * may not be quantifiable until run time, and only then is the * necessary code is written. The standard says we should say * something about this issue in the documentation... @@ -162,7 +158,7 @@ * * At this time all functions EXCEPT clock_nanosleep can be * redirected by the CLOCKS structure. Clock_nanosleep is in - * there, but the code ignors it. + * there, but the code ignores it. * * Permissions: It is assumed that the clock_settime() function defined * for each clock will take care of permission checks. Some @@ -198,6 +194,8 @@ struct timespec *tp, struct timespec *mo); int do_posix_clock_monotonic_gettime(struct timespec *tp); int do_posix_clock_monotonic_settime(struct timespec *tp); +int do_posix_clock_process_gettime(struct timespec *tp); +int do_posix_clock_thread_gettime(struct timespec *tp); static struct k_itimer *lock_timer(timer_t timer_id, unsigned long *flags); static inline void unlock_timer(struct k_itimer *timr, unsigned long flags) @@ -218,6 +216,14 @@ .clock_get = do_posix_clock_monotonic_gettime, .clock_set = do_posix_clock_monotonic_settime }; + struct k_clock clock_thread = {.res = CLOCK_REALTIME_RES, + .abs_struct = NULL, + .clock_get = do_posix_clock_thread_gettime + }; + struct k_clock clock_process = {.res = CLOCK_REALTIME_RES, + .abs_struct = NULL, + .clock_get = do_posix_clock_process_gettime + }; #ifdef CONFIG_TIME_INTERPOLATION /* Clocks are more accurate with time interpolators */ @@ -226,6 +232,8 @@ register_posix_clock(CLOCK_REALTIME, &clock_realtime); register_posix_clock(CLOCK_MONOTONIC, &clock_monotonic); + register_posix_clock(CLOCK_PROCESS_CPUTIME_ID, &clock_process); + register_posix_clock(CLOCK_THREAD_CPUTIME_ID, &clock_thread); posix_timers_cache = kmem_cache_create("posix_timers_cache", sizeof (struct k_itimer), 0, 0, NULL, NULL); @@ -1227,6 +1235,46 @@ return -EINVAL; } +/* + * Single Unix Specification V3: + * + * Implementations shall also support the special clockid_t value + * CLOCK_THREAD_CPUTIME_ID, which represents the CPU-time clock of the calling + * thread when invoking one of the clock_*() or timer_*() functions. For these + * clock IDs, the values returned by clock_gettime() and specified by + * clock_settime() shall represent the amount of execution time of the thread + * associated with the clock. + */ +int do_posix_clock_thread_gettime(struct timespec *tp) +{ + jiffies_to_timespec(current->signal->cutime + current->signal->cstime, tp); + return 0; +} + +/* + * Single Unix Specification V3: + * + * Implementations shall also support the special clockid_t value + * CLOCK_PROCESS_CPUTIME_ID, which represents the CPU-time clock of the + * calling process when invoking one of the clock_*() or timer_*() functions. + * For these clock IDs, the values returned by clock_gettime() and specified + * by clock_settime() represent the amount of execution time of the process + * associated with the clock. + */ +int do_posix_clock_process_gettime(struct timespec *tp) +{ + unsigned long ticks = 0; + struct task *t; + + /* Add up the cpu time for all the threads of this process */ + for (t = current; t != current; t = next_thread(p)) { + ticks += t->signal->cutime + t->signal->cstime; + } + + jiffies_to_timespec(ticks, tp); + return 0; +} + asmlinkage long sys_clock_settime(clockid_t which_clock, const struct timespec __user *tp) { ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] Posix compliant behavior of CLOCK_PROCESS/THREAD_CPUTIME_ID 2004-09-27 20:58 ` [RFC] Posix compliant behavior of CLOCK_PROCESS/THREAD_CPUTIME_ID Christoph Lameter @ 2004-09-28 19:18 ` Ulrich Drepper 2004-09-29 3:25 ` Posix compliant CLOCK_PROCESS/THREAD_CPUTIME_ID V4 Christoph Lameter 0 siblings, 1 reply; 7+ messages in thread From: Ulrich Drepper @ 2004-09-28 19:18 UTC (permalink / raw) To: Christoph Lameter Cc: johnstul, Ulrich.Windl, george, linux-kernel, libc-alpha -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I'm not the right person to comment on this, I hope Roland will. Roland has been working on an implementation of this clock. I think the situation is quite a bit more complicated than your patch suggests. So, please wait until he has time to comment. - -- ➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFBWbkg2ijCOnn/RHQRArRbAJ9jEv/jwYuHuxQeT7fITmBAixaP2wCfcu0e Ysb9uKlNxF58eycti8tA2us= =AHNp -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 7+ messages in thread
* Posix compliant CLOCK_PROCESS/THREAD_CPUTIME_ID V4 2004-09-28 19:18 ` Ulrich Drepper @ 2004-09-29 3:25 ` Christoph Lameter 2004-09-29 17:45 ` George Anzinger 0 siblings, 1 reply; 7+ messages in thread From: Christoph Lameter @ 2004-09-29 3:25 UTC (permalink / raw) To: Ulrich Drepper Cc: johnstul, Ulrich.Windl, george, jbarnes, linux-kernel, libc-alpha George asked for a test program so I wrote one and debugged the patch. The test program uses syscall to bypass glibc processing. I have been working on a patch for glibc but that gets a bit complicated because backwards compatibility has to be kept. Maybe tomorrow. Found also that glibc allows the setting of these clocks so I also implemented that and used it in the test program. Setting these clocks modifies stime and utime directly, which may not be such a good idea. Do we really need to be able to set these clocks? So it actually works now. Test output, test program and revised patch: christoph@athlon:~$ ./test_cputime Single Thread Testing CLOCK_THREAD_CPUTIME_ID= 0.373943152 resolution= 0.000999848 CLOCK_PROCESS_CPUTIME_ID= 0.373943152 resolution= 0.000999848 Multi Thread Testing Starting Thread: 0 1 2 3 4 5 6 7 8 9 Joining Thread: 0 1 2 3 4 5 6 7 8 9 0 Cycles= 0 Thread= 0.000000000ns Process= 0.000000000ns 1 Cycles=1000000 Thread= 0.037994224ns Process= 0.507922784ns 2 Cycles=2000000 Thread= 0.073988752ns Process= 0.097985104ns 3 Cycles=3000000 Thread= 0.108983432ns Process= 0.612906824ns 4 Cycles=4000000 Thread= 0.146977656ns Process= 0.657899984ns 5 Cycles=5000000 Thread= 0.182972184ns Process= 0.739887520ns 6 Cycles=6000000 Thread= 0.217966864ns Process= 1.456778536ns 7 Cycles=7000000 Thread= 0.254961240ns Process= 1.461777776ns 8 Cycles=8000000 Thread= 0.290955768ns Process= 1.627752544ns 9 Cycles=9000000 Thread= 0.326950296ns Process= 1.641750416ns Clock status at the end of the timer tests: Gettimeofday() = 1096427813.738929000 CLOCK_REALTIME= 1096427813.738941000 resolution= 0.000999848 CLOCK_MONOTONIC= 161.938418328 resolution= 0.000999848 CLOCK_PROCESS_CPUTIME_ID= 1.641750416 resolution= 0.000999848 CLOCK_THREAD_CPUTIME_ID= 0.000000000 resolution= 0.000999848 #include <stdio.h> #include <stdlib.h> #include <time.h> #include <errno.h> #include <asm/unistd.h> #include <pthread.h> #define clock_getres(x,y) syscall(__NR_clock_getres, x,y) #define clock_gettime(x,y) syscall(__NR_clock_gettime, x, y) #define clock_settime(x,y) syscall(__NR_clock_settime, x, y) void pr(int clock,const char *n) { struct timespec tv = {1,2}; struct timespec res = {3,4}; int rc; rc=clock_getres(clock,&res); if (rc) { printf("getres return code on %s=%d errno=%d\n",n,rc,errno); } rc=clock_gettime(clock,&tv); if (rc) { printf("gettime return code on %s=%d errno=%d\n",n,rc, errno); } else printf("%25s=% 11d.%09d resolution=% 2d.%09d\n",n,tv.tv_sec,tv.tv_nsec,res.tv_sec,res.tv_nsec); } int y; void kx(long long x) { y=x; }; struct timespec zero; pthread_t thread[10]; struct tinfo { int i; struct timespec ttime,ptime; } tinf[10]; void *thread_function(void *x) { struct tinfo *t=x; int i; for(i=1;i< t->i;i++) kx(1000000000000LL/i); clock_gettime(CLOCK_THREAD_CPUTIME_ID,&t->ttime); clock_gettime(CLOCK_PROCESS_CPUTIME_ID,&t->ptime); } int main(char argc, char *argv[]) { struct timespec tv; int i; /* Waste some time */ printf("Single Thread Testing\n"); for(i=1;i<10000000;i++) kx(1000000000000LL/i); pr(CLOCK_THREAD_CPUTIME_ID,"CLOCK_THREAD_CPUTIME_ID"); pr(CLOCK_PROCESS_CPUTIME_ID,"CLOCK_PROCESS_CPUTIME_ID"); /* Waste some more time in threads */ printf("Multi Thread Testing\nStarting Thread:"); clock_settime(CLOCK_PROCESS_CPUTIME_ID,&zero); for(i=0;i<10;i++) { tinf[i].i=i*1000000; if (pthread_create(&thread[i], NULL, thread_function, tinf+i)) perror("thread"); else printf(" %d",i); } printf("\n Joining Thread:"); for(i=0;i<10;i++) if (pthread_join( thread[i], NULL)) perror("join"); else printf(" %d",i); printf("\n"); for(i=0;i<10;i++) { printf("%d Cycles=%7d Thread=% 3d.%09dns Process=% 3d.%09dns\n",i,tinf[i].i,tinf[i].ttime.tv_sec,tinf[i].ttime.tv_nsec,tinf[i].ptime.tv_sec,tinf[i].ptime.tv_nsec); } gettimeofday((struct timeval *)&tv); tv.tv_nsec = tv.tv_nsec*1000; printf("\nClock status at the end of the timer tests:\n"); printf(" Gettimeofday() =% 11d.%09d\n",tv.tv_sec,tv.tv_nsec); pr(CLOCK_REALTIME,"CLOCK_REALTIME"); pr(CLOCK_MONOTONIC,"CLOCK_MONOTONIC"); pr(CLOCK_PROCESS_CPUTIME_ID,"CLOCK_PROCESS_CPUTIME_ID"); pr(CLOCK_THREAD_CPUTIME_ID,"CLOCK_THREAD_CPUTIME_ID"); printf("\n"); } Index: linux-2.6.9-rc2/kernel/posix-timers.c =================================================================== --- linux-2.6.9-rc2.orig/kernel/posix-timers.c 2004-09-12 22:32:48.000000000 -0700 +++ linux-2.6.9-rc2/kernel/posix-timers.c 2004-09-28 19:49:59.919624581 -0700 @@ -10,6 +10,10 @@ * 2004-06-01 Fix CLOCK_REALTIME clock/timer TIMER_ABSTIME bug. * Copyright (C) 2004 Boris Hu * + * 2004-07-27 Provide POSIX compliant clocks + * CLOCK_PROCESS_CPUTIME_ID and CLOCK_THREAD_CPUTIME_ID. + * by Christoph Lameter + * * This program is free software; you can redistribute it and/or modify * it under the terms of the GNU General Public License as published by * the Free Software Foundation; either version 2 of the License, or (at @@ -133,18 +137,10 @@ * resolution. Here we define the standard CLOCK_REALTIME as a * 1/HZ resolution clock. * - * CPUTIME & THREAD_CPUTIME: We are not, at this time, definding these - * two clocks (and the other process related clocks (Std - * 1003.1d-1999). The way these should be supported, we think, - * is to use large negative numbers for the two clocks that are - * pinned to the executing process and to use -pid for clocks - * pinned to particular pids. Calls which supported these clock - * ids would split early in the function. - * * RESOLUTION: Clock resolution is used to round up timer and interval * times, NOT to report clock times, which are reported with as * much resolution as the system can muster. In some cases this - * resolution may depend on the underlaying clock hardware and + * resolution may depend on the underlying clock hardware and * may not be quantifiable until run time, and only then is the * necessary code is written. The standard says we should say * something about this issue in the documentation... @@ -162,7 +158,7 @@ * * At this time all functions EXCEPT clock_nanosleep can be * redirected by the CLOCKS structure. Clock_nanosleep is in - * there, but the code ignors it. + * there, but the code ignores it. * * Permissions: It is assumed that the clock_settime() function defined * for each clock will take care of permission checks. Some @@ -198,6 +194,10 @@ struct timespec *tp, struct timespec *mo); int do_posix_clock_monotonic_gettime(struct timespec *tp); int do_posix_clock_monotonic_settime(struct timespec *tp); +int do_posix_clock_process_gettime(struct timespec *tp); +int do_posix_clock_process_settime(struct timespec *tp); +int do_posix_clock_thread_gettime(struct timespec *tp); +int do_posix_clock_thread_settime(struct timespec *tp); static struct k_itimer *lock_timer(timer_t timer_id, unsigned long *flags); static inline void unlock_timer(struct k_itimer *timr, unsigned long flags) @@ -218,6 +218,16 @@ .clock_get = do_posix_clock_monotonic_gettime, .clock_set = do_posix_clock_monotonic_settime }; + struct k_clock clock_thread = {.res = CLOCK_REALTIME_RES, + .abs_struct = NULL, + .clock_get = do_posix_clock_thread_gettime, + .clock_set = do_posix_clock_thread_settime + }; + struct k_clock clock_process = {.res = CLOCK_REALTIME_RES, + .abs_struct = NULL, + .clock_get = do_posix_clock_process_gettime, + .clock_set = do_posix_clock_process_settime + }; #ifdef CONFIG_TIME_INTERPOLATION /* Clocks are more accurate with time interpolators */ @@ -226,6 +236,8 @@ register_posix_clock(CLOCK_REALTIME, &clock_realtime); register_posix_clock(CLOCK_MONOTONIC, &clock_monotonic); + register_posix_clock(CLOCK_PROCESS_CPUTIME_ID, &clock_process); + register_posix_clock(CLOCK_THREAD_CPUTIME_ID, &clock_thread); posix_timers_cache = kmem_cache_create("posix_timers_cache", sizeof (struct k_itimer), 0, 0, NULL, NULL); @@ -1227,6 +1239,76 @@ return -EINVAL; } +/* + * Single Unix Specification V3: + * + * Implementations shall also support the special clockid_t value + * CLOCK_THREAD_CPUTIME_ID, which represents the CPU-time clock of the calling + * thread when invoking one of the clock_*() or timer_*() functions. For these + * clock IDs, the values returned by clock_gettime() and specified by + * clock_settime() shall represent the amount of execution time of the thread + * associated with the clock. + */ +int do_posix_clock_thread_gettime(struct timespec *tp) +{ + jiffies_to_timespec(current->utime + current->stime, tp); + return 0; +} + +int do_posix_clock_thread_settime(struct timespec *tp) +{ + current->stime = 0; + current->utime = timespec_to_jiffies(tp); + return 0; +} + +/* + * Single Unix Specification V3: + * + * Implementations shall also support the special clockid_t value + * CLOCK_PROCESS_CPUTIME_ID, which represents the CPU-time clock of the + * calling process when invoking one of the clock_*() or timer_*() functions. + * For these clock IDs, the values returned by clock_gettime() and specified + * by clock_settime() represent the amount of execution time of the process + * associated with the clock. + */ +int do_posix_clock_process_gettime(struct timespec *tp) +{ + unsigned long ticks; + task_t *t; + + /* The signal structure is shared between all threads */ + ticks = current->signal->utime + current->signal->stime; + + /* Add up the cpu time for all the still running threads of this process */ + t = current; + do { + ticks += t->utime + t->stime; + t = next_thread(t); + } while (t != current); + + jiffies_to_timespec(ticks, tp); + return 0; +} + +int do_posix_clock_process_settime(struct timespec *tp) +{ + task_t *t; + /* + * Set all other threads to zero cs/cutime and then set up the + * desired time in the current thread + */ + + for (t = next_thread(current); t != current; t = next_thread(t)) + { + t->stime = 0; + t->utime = 0; + } + + do_posix_clock_thread_settime(tp); + return 0; +} + asmlinkage long sys_clock_settime(clockid_t which_clock, const struct timespec __user *tp) { ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Posix compliant CLOCK_PROCESS/THREAD_CPUTIME_ID V4 2004-09-29 3:25 ` Posix compliant CLOCK_PROCESS/THREAD_CPUTIME_ID V4 Christoph Lameter @ 2004-09-29 17:45 ` George Anzinger [not found] ` <B6E8046E1E28D34EB815A11AC8CA31290322B307@mtv-atc-605e--n.corp.sgi.com> 0 siblings, 1 reply; 7+ messages in thread From: George Anzinger @ 2004-09-29 17:45 UTC (permalink / raw) To: Christoph Lameter Cc: Ulrich Drepper, johnstul, Ulrich.Windl, jbarnes, linux-kernel, libc-alpha Christoph Lameter wrote: > George asked for a test program so I wrote one and debugged the patch. > The test program uses syscall to bypass glibc processing. I have been > working on a patch for glibc but that gets a bit complicated > because backwards compatibility has to be kept. Maybe tomorrow. > Found also that glibc allows the setting of these clocks so I also > implemented that and used it in the test program. Setting these > clocks modifies stime and utime directly, which may not be such a good > idea. Do we really need to be able to set these clocks? Another way of doing this is to save these values in the task structure. If null, use the direct value of stime, utime, if not, adjust by the saved value (i.e. saved value would represent time zero). > > So it actually works now. Test output, test program and revised patch: Please, when sending patches, attach them. This avoids problems with mailers, on both ends, messing with white space. They still appear in line, at least in some mailers (mozilla in my case). As to the test program, what happens when you attempt to set up a timer on these clocks? (No, I don't think it should work, but we DO want to properly error out. And the test should verify that this happens.) By the way, if you use the support package from sourceforge, you will find a lot of test harness stuff. ~ -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <B6E8046E1E28D34EB815A11AC8CA31290322B307@mtv-atc-605e--n.corp.sgi.com>]
* Posix compliant cpu clocks V7 [0/2]: Rationale and test program [not found] ` <B6E8046E1E28D34EB815A11AC8CA31290322B307@mtv-atc-605e--n.corp.sgi.com> @ 2004-10-07 4:56 ` Christoph Lameter 2004-10-12 20:19 ` Periodic posix timer support broke between 2.6.9-rc1 and 2.6.9-rc1-bk17 Christoph Lameter 0 siblings, 1 reply; 7+ messages in thread From: Christoph Lameter @ 2004-10-07 4:56 UTC (permalink / raw) To: George Anzinger Cc: Ulrich Drepper, johnstul, Ulrich.Windl, jbarnes, akpm, linux-kernel, libc-alpha, nickpiggin, roland Posix compliant cpu clocks: V7 [0/3] Rationale and test program Signed-off-by: Christoph Lameter <clameter@sgi.com> Changes from V5: * add a simple means of accessing other processes cputimers. * Simplified glibc patch that makes glibc return errors when an applications accesses cputimers and is run with glibc under a kernel not providing cputimers. This may allow the detection of applications that need to be updated since they depend on the earlier non posix compliant version of glibc. Also should be more readable since the sections are no longer moved betweeen directory hierachies. * remove ability to set process and thread clocks. POSIX clocks are to be implemented in the following way according to V3 of the Single Unix Specification: 1. CLOCK_PROCESS_CPUTIME_ID Implementations shall also support the special clockid_t value CLOCK_PROCESS_CPUTIME_ID, which represents the CPU-time clock of the calling process when invoking one of the clock_*() or timer_*() functions. For these clock IDs, the values returned by clock_gettime() and specified by clock_settime() represent the amount of execution time of the process associated with the clock. 2. CLOCK_THREAD_CPUTIME_ID Implementations shall also support the special clockid_t value CLOCK_THREAD_CPUTIME_ID, which represents the CPU-time clock of the calling thread when invoking one of the clock_*() or timer_*() functions. For these clock IDs, the values returned by clock_gettime() and specified by clock_settime() shall represent the amount of execution time of the thread associated with the clock. These times mentioned are CPU processing times and not the time that has passed since the startup of a process. Glibc currently provides its own implementation of these two clocks which is designed to return the time that passed since the startup of a process or a thread. Moreover Glibc's clocks are bound to CPU timers which is problematic when the frequency of the clock changes or the process is moved to a different processor whose cpu timer may not be fully synchronized to the cpu timer of the current CPU. This patchset results in a both clocks working reliably. The patch also implements the access to other the thread and process clocks of linux processes by using negative clockid's: 1. For CLOCK_PROCESS_CPUTIME_ID: -pid 2. For CLOCK_THREAD_CPUTIME_ID: -(pid + PID_MAX_LIMIT) This allows clock_getcpuclockid(pid) to return -pid and pthread_getcpuiclock(pid) to return -(pid + PID_MAX_LIMIT) to allow access to the corresponding clocks. Todo: - The timer API to generate events by a non tick based timer is not usable in its current state. The posix timer API seems to be only useful at this point to define clock_get/set. Need to revise this. - Implement timed interrupts in mmtimer after API is revised. The patchset consists of the following components: [0/2] Contains an explanation as to why these patches are necessary as well as a test program and the output of a sample run. [1/2] Linux Kernel Patch: Implements the two clocks and enhances some pieces of the posix-timers implementation in the kernel for these clocks and also makes it possible for device drivers to define additional clocks. [2/2] Glibc patch: Use kernel clocks and also makes glibc able to use any posix clock provided by the kernel so that posix clocks by driver may be accessed. Break apps that use the old cputimer based CLOCK_*_CPUTIME_IDs on kernels that do not support CLOCK_*_CPUTIME_ID. The mmtimer patch is unchanged from V6 and stays as is in 2.6.9-rc3-mm2. But I expect to update the driver as soon as the interface to setup hardware timer interrupts is usable. Rolands patches: ---------------- This patch is not as comprehensive as Rolands but also not as invasive. Roland's high resolution time through tsc is a hack but would significantly improve the statistics we get for a process. However, we may get the same result in a cleaner way after John Stultz and my plan for revising the time subsystem is through. This would replace jiffies with nanoseconds for time keeping throughout the kernel. Nanosecond accuracy is already available through getnstimeofday() on some platforms. Some of the functionality in Roland's patch may be implemented in a TSC independent way using this function. The use of negative pid values in certain numeric ranges for selecting the type of clock is something that is also in a simplerr way present in my patch. I do not like this and would rather see this incorporated in glibc if the glibc people can come up with a sane implementation. Single Thread Testing CLOCK_THREAD_CPUTIME_ID= 0.494140878 resolution= 0.000976563 CLOCK_PROCESS_CPUTIME_ID= 0.494140878 resolution= 0.000976563 Multi Thread Testing Starting Thread: 0 1 2 3 4 5 6 7 8 9 Joining Thread: 0 1 2 3 4 5 6 7 8 9 0 Cycles= 0 Thread= 0.000000000ns Process= 0.495117441ns 1 Cycles=1000000 Thread= 0.140625072ns Process= 2.523438792ns 2 Cycles=2000000 Thread= 0.966797370ns Process= 8.512699671ns 3 Cycles=3000000 Thread= 0.806641038ns Process= 7.561527309ns 4 Cycles=4000000 Thread= 1.865235330ns Process= 12.891608163ns 5 Cycles=5000000 Thread= 1.604493009ns Process= 11.528326215ns 6 Cycles=6000000 Thread= 2.086915131ns Process= 13.500983475ns 7 Cycles=7000000 Thread= 2.245118337ns Process= 13.947272766ns 8 Cycles=8000000 Thread= 1.604493009ns Process= 12.252935961ns 9 Cycles=9000000 Thread= 2.160157356ns Process= 13.977546219ns Clock status at the end of the timer tests: Gettimeofday() = 1097084999.489938000 CLOCK_REALTIME= 1097084999.490116229 resolution= 0.000000040 CLOCK_MONOTONIC= 177.071675109 resolution= 0.000000040 CLOCK_PROCESS_CPUTIME_ID= 13.978522782 resolution= 0.000976563 CLOCK_THREAD_CPUTIME_ID= 0.497070567 resolution= 0.000976563 CLOCK_SGI_CYCLE= 229.967982280 resolution= 0.000000040 PROCESS clock of 1 (init)= 4.833986850 resolution= 0.000976563 THREAD clock of 1 (init)= 0.009765630 resolution= 0.000976563 #include <stdio.h> #include <stdlib.h> #include <time.h> #include <errno.h> #include <asm/unistd.h> #include <pthread.h> #define clock_getres(x,y) syscall(__NR_clock_getres, x,y) #define clock_gettime(x,y) syscall(__NR_clock_gettime, x, y) #define clock_settime(x,y) syscall(__NR_clock_settime, x, y) void pr(int clock,const char *n) { struct timespec tv = {1,2}; struct timespec res = {3,4}; int rc; rc=clock_getres(clock,&res); if (rc) { printf("getres return code on %s=%d errno=%d\n",n,rc,errno); } rc=clock_gettime(clock,&tv); if (rc) { printf("gettime return code on %s=%d errno=%d\n",n,rc, errno); } else printf("%25s=% 11d.%09d resolution=% 2d.%09d\n",n,tv.tv_sec,tv.tv_nsec,res.tv_sec,res.tv_nsec); } int y; void kx(long long x) { y=x; }; struct timespec zero; pthread_t thread[10]; struct tinfo { int i; struct timespec ttime,ptime; } tinf[10]; void *thread_function(void *x) { struct tinfo *t=x; int i; for(i=1;i< t->i;i++) kx(1000000000000LL/i); clock_gettime(CLOCK_THREAD_CPUTIME_ID,&t->ttime); clock_gettime(CLOCK_PROCESS_CPUTIME_ID,&t->ptime); } int main(char argc, char *argv[]) { struct timespec tv; int i; /* Waste some time */ printf("Single Thread Testing\n"); for(i=1;i<10000000;i++) kx(1000000000000LL/i); pr(CLOCK_THREAD_CPUTIME_ID,"CLOCK_THREAD_CPUTIME_ID"); pr(CLOCK_PROCESS_CPUTIME_ID,"CLOCK_PROCESS_CPUTIME_ID"); /* Waste some more time in threads */ printf("Multi Thread Testing\nStarting Thread:"); clock_settime(CLOCK_PROCESS_CPUTIME_ID,&zero); for(i=0;i<10;i++) { tinf[i].i=i*1000000; if (pthread_create(&thread[i], NULL, thread_function, tinf+i)) perror("thread"); else printf(" %d",i); } printf("\n Joining Thread:"); for(i=0;i<10;i++) if (pthread_join( thread[i], NULL)) perror("join"); else printf(" %d",i); printf("\n"); for(i=0;i<10;i++) { printf("%d Cycles=%7d Thread=% 3d.%09dns Process=% 3d.%09dns\n",i,tinf[i].i,tinf[i].ttime.tv_sec,tinf[i].ttime.tv_nsec,tinf[i].ptime.tv_sec,tinf[i].ptime.tv_nsec); } gettimeofday((struct timeval *)&tv); tv.tv_nsec = tv.tv_nsec*1000; printf("\nClock status at the end of the timer tests:\n"); printf(" Gettimeofday() =% 11d.%09d\n",tv.tv_sec,tv.tv_nsec); pr(CLOCK_REALTIME,"CLOCK_REALTIME"); pr(CLOCK_MONOTONIC,"CLOCK_MONOTONIC"); pr(CLOCK_PROCESS_CPUTIME_ID,"CLOCK_PROCESS_CPUTIME_ID"); pr(CLOCK_THREAD_CPUTIME_ID,"CLOCK_THREAD_CPUTIME_ID"); pr(10,"CLOCK_SGI_CYCLE"); pr(-1,"PROCESS clock of 1 (init)"); pr(-1 - 4*1024*1024,"THREAD clock of 1 (init)"); printf("\n"); } ^ permalink raw reply [flat|nested] 7+ messages in thread
* Periodic posix timer support broke between 2.6.9-rc1 and 2.6.9-rc1-bk17 2004-10-07 4:56 ` Posix compliant cpu clocks V7 [0/2]: Rationale and test program Christoph Lameter @ 2004-10-12 20:19 ` Christoph Lameter 2004-10-12 22:24 ` George Anzinger 2004-10-13 18:08 ` Alexander Nyberg 0 siblings, 2 replies; 7+ messages in thread From: Christoph Lameter @ 2004-10-12 20:19 UTC (permalink / raw) To: George Anzinger; +Cc: johnstul, Ulrich.Windl, jbarnes, linux-kernel, roland I ran some test programs and discovered that the periodic timer support is broken. The timer is triggered once and then never again. Single shot timers work fine. 2.6.9-rc1 is fine. The first kernel that I tested where I noticed the breakage was 2.6.9-rc1-bk17. 2.6.9-rc2 and following all cannot do periodic timer signals. I looked through the changelog but I cannot see anything that would cause the problem. Roland's patch surely could not have done this. Will try to track this down further, time permitting... ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Periodic posix timer support broke between 2.6.9-rc1 and 2.6.9-rc1-bk17 2004-10-12 20:19 ` Periodic posix timer support broke between 2.6.9-rc1 and 2.6.9-rc1-bk17 Christoph Lameter @ 2004-10-12 22:24 ` George Anzinger 2004-10-13 18:08 ` Alexander Nyberg 1 sibling, 0 replies; 7+ messages in thread From: George Anzinger @ 2004-10-12 22:24 UTC (permalink / raw) To: Christoph Lameter; +Cc: johnstul, Ulrich.Windl, jbarnes, linux-kernel, roland Christoph Lameter wrote: > I ran some test programs and discovered that the periodic timer support > is broken. The timer is triggered once and then never again. Single shot > timers work fine. 2.6.9-rc1 is fine. The first kernel that I tested where > I noticed the breakage was 2.6.9-rc1-bk17. 2.6.9-rc2 and following all > cannot do periodic timer signals. > > I looked through the changelog but I cannot see anything that would cause > the problem. Roland's patch surely could not have done this. > > Will try to track this down further, time permitting... The most likely thing would be failure to do the call back from the signal delivery code. -- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Periodic posix timer support broke between 2.6.9-rc1 and 2.6.9-rc1-bk17 2004-10-12 20:19 ` Periodic posix timer support broke between 2.6.9-rc1 and 2.6.9-rc1-bk17 Christoph Lameter 2004-10-12 22:24 ` George Anzinger @ 2004-10-13 18:08 ` Alexander Nyberg 2004-10-13 18:11 ` Christoph Lameter 1 sibling, 1 reply; 7+ messages in thread From: Alexander Nyberg @ 2004-10-13 18:08 UTC (permalink / raw) To: Christoph Lameter Cc: George Anzinger, johnstul, Ulrich.Windl, jbarnes, linux-kernel, roland, Ingo Molnar > I ran some test programs and discovered that the periodic timer support > is broken. The timer is triggered once and then never again. Single shot > timers work fine. 2.6.9-rc1 is fine. The first kernel that I tested where > I noticed the breakage was 2.6.9-rc1-bk17. 2.6.9-rc2 and following all > cannot do periodic timer signals. > > I looked through the changelog but I cannot see anything that would cause > the problem. Roland's patch surely could not have done this. > > Will try to track this down further, time permitting... I took a bit of a look at this, and it looks like some things changed with the introduction of the flexible mmap in 2.6.9-rc1-bk1. If you run the program below it will work, doing as expected. Now comment out the the line "memset(&sa, 0, sizeof(struct sigaction));" and program won't run as expected. Now do "echo -n 1 > /proc/sys/vm/legacy_va_layout" and run the same program again (the one with memset commented out). Turning on signal debugging tells us that with legacy_va_layout=0 "SIG deliver (a.out:415): sp=bffff6c0 pc=08048434 ra=00000000" where ra is the 8-byte instruction that's supposed to get us back to sys_sigreturn(). Me thinks someone somewhere is using some of the bits that we "accidently" pass via sa.sa_flags by not setting it to 0, the regular flags don't seem to show this behaviour, and I couldn't see any real checking of the passed value of sa.sa_flags. --------------------------------------------------------- #include <stdio.h> #include <stdlib.h> #include <signal.h> #include <sys/time.h> void sighandler(int signal) { printf("hihi\n"); } int main() { struct itimerval timeval; struct sigaction sa; memset(&timeval, 0, sizeof(struct timeval)); memset(&sa, 0, sizeof(struct sigaction)); sa.sa_handler = &sighandler; sigfillset(&sa.sa_mask); sigaction(SIGALRM, &sa, NULL); timeval.it_interval.tv_sec = 2; timeval.it_interval.tv_usec = 0; timeval.it_value.tv_sec = 2; timeval.it_value.tv_usec = 0; if (setitimer(ITIMER_REAL, &timeval, NULL)) printf("Nooo!\n"); for(;;) ; return 0; } ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Periodic posix timer support broke between 2.6.9-rc1 and 2.6.9-rc1-bk17 2004-10-13 18:08 ` Alexander Nyberg @ 2004-10-13 18:11 ` Christoph Lameter 0 siblings, 0 replies; 7+ messages in thread From: Christoph Lameter @ 2004-10-13 18:11 UTC (permalink / raw) To: Alexander Nyberg Cc: George Anzinger, johnstul, Ulrich.Windl, jbarnes, linux-kernel, roland, Ingo Molnar > Me thinks someone somewhere is using some of the bits that we > "accidently" pass via sa.sa_flags by not setting it to 0, the regular > flags don't seem to show this behaviour, and I couldn't see any real > checking of the passed value of sa.sa_flags. Nope. It was my screwed up setting of the resolution of CLOCK_REALTIME and CLOCK_MONOTONIC. Fix was submitted to Linus and Andrew. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2004-10-13 18:12 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-13 16:03 Periodic posix timer support broke between 2.6.9-rc1 and Christoph Lameter
2004-10-13 17:25 ` Periodic posix timer support broke between 2.6.9-rc1 and 2.6.9-rc1-bk17 George Anzinger
2004-10-13 17:29 ` Periodic posix timer support broke between 2.6.9-rc1 and Christoph Lameter
[not found] <B6E8046E1E28D34EB815A11AC8CA312902CD3264@mtv-atc-605e--n.corp.sgi.com>
2004-09-24 12:16 ` [time] add support for CLOCK_THREAD_CPUTIME_ID and CLOCK_PROCESS_CPUTIME_ID Christoph Lameter
2004-09-25 4:25 ` Ulrich Drepper
2004-09-25 5:54 ` Christoph Lameter
2004-09-25 6:08 ` Ulrich Drepper
[not found] ` <B6E8046E1E28D34EB815A11AC8CA312902CD327E@mtv-atc-605e--n.corp.sgi.com>
2004-09-27 20:58 ` [RFC] Posix compliant behavior of CLOCK_PROCESS/THREAD_CPUTIME_ID Christoph Lameter
2004-09-28 19:18 ` Ulrich Drepper
2004-09-29 3:25 ` Posix compliant CLOCK_PROCESS/THREAD_CPUTIME_ID V4 Christoph Lameter
2004-09-29 17:45 ` George Anzinger
[not found] ` <B6E8046E1E28D34EB815A11AC8CA31290322B307@mtv-atc-605e--n.corp.sgi.com>
2004-10-07 4:56 ` Posix compliant cpu clocks V7 [0/2]: Rationale and test program Christoph Lameter
2004-10-12 20:19 ` Periodic posix timer support broke between 2.6.9-rc1 and 2.6.9-rc1-bk17 Christoph Lameter
2004-10-12 22:24 ` George Anzinger
2004-10-13 18:08 ` Alexander Nyberg
2004-10-13 18:11 ` Christoph Lameter
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.