Messages in this thread | | | Date | Mon, 13 Dec 2004 19:53:31 -0800 | From | Roland McGrath <> | Subject | [PATCH 0/7 (introduction)] cpu-timers and friends |
| |
This message is to introduce the coming seven messages. These relate to process/thread CPU-time clocks for POSIX timers and some related fixes for proper POSIX semantics in multithreaded programs (under NPTL).
These patches were made against a recent current tree, plus my stoprace-fix signals patch. That patch follow-on and the group_exit cleanup are already in 2.6.10-rc3-mm1, but these patches were made against a Linus tree with just the stoprace-fix patch. (That fix is necessary for some of these changes to be safe, while the group_exit cleanup is just a non-bug cleanup.) If you need these patches remade against -mm or some other given tree state, please let me know. I'm happy to do whatever makes it easiest to get them into the tree ASAP.
Note that the first patch changes an ill-advised new user-kernel ABI that has been introduced since 2.6.9; I really think we should not let the existing clockid_t encoding change get out in 2.6.10. I hope this patch (and ideally all the rest) can go into 2.6.10, but reverting the earlier patch so that we have no new clockid_t values at all would be better than letting the existing code for CPU clocks make it into 2.6.10, IMHO.
These can also be found in http://people.redhat.com/roland/kernel-patches/ Not all of the changes are strict dependencies, but these patches will need to be applied in the order of posting, which is:
linux-2.6.10rc3-cpuclocks.patch linux-2.6.10rc2-timer-signal-deadlock-fix.patch linux-2.6.10rc3-cputimers.patch linux-2.6.10rc3-process-itimer-real.patch linux-2.6.10rc3-process-itimer-cpu.patch linux-2.6.10rc3-process-sigxcpu.patch linux-2.6.10rc3-timer-cleanup.patch
In http://people.redhat.com/roland/glibc/ you can find a glibc patch to enable using the new clock_* and timer_* kernel support. This includes some test programs. I've tested the kernel code using these programs, on a 2-CPU x86 machine. There shouldn't be anything machine-dependent about the code, but architectures vary on how good the time they implement for `sched_clock' is; on some, it's nothing but the same jiffies-based count you see via getrusage.
Thanks, Roland - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |