From: Erich F. <ef...@hp...> - 2003-07-18 16:32:27
Attachments:
cputimes_stat-2.6.0t1.patch
|
This patch brings back the per CPU user & system times which one was used to see in /proc/PID/cpu with 2.4 kernels. Useful for SMP and NUMA scheduler development, needed for reasonable output in numabench / numa_test. Regards, Erich |
From: Mike K. <kr...@us...> - 2003-07-18 18:47:12
|
On Fri, Jul 18, 2003 at 06:35:42PM +0200, Erich Focht wrote: > > This patch brings back the per CPU user & system times which one was > used to see in /proc/PID/cpu with 2.4 kernels. Useful for SMP and NUMA > scheduler development, needed for reasonable output in numabench / > numa_test. > On a somewhat related note ... We (Big Blue) have a performance reporting application that would like to know how long a task sits on a runqueue before it is actually given the CPU. In other words, it wants to know how long the 'runnable task' was delayed due to contention for the CPU(s). Of course, one could get an overall feel for this based on total runqueue length. However, this app would really like this info on a per-task basis. Does anyone else think this type of info would be useful? A patch to compute/export this info should be straight forward to implement. -- Mike |
From: William L. I. I. <wl...@ho...> - 2003-07-18 19:57:54
|
On Fri, Jul 18, 2003 at 11:18:50AM -0700, Mike Kravetz wrote: > On a somewhat related note ... > We (Big Blue) have a performance reporting application that > would like to know how long a task sits on a runqueue before > it is actually given the CPU. In other words, it wants to > know how long the 'runnable task' was delayed due to contention > for the CPU(s). Of course, one could get an overall feel for > this based on total runqueue length. However, this app would > really like this info on a per-task basis. > Does anyone else think this type of info would be useful? > A patch to compute/export this info should be straight forward > to implement. I wrote something to collect the standard queueing statistics a while back but am not sure what I did with it. I think Rick Lindsley might still have a copy around. -- wli |
From: Peter C. <pe...@ch...> - 2003-07-21 04:48:17
|
>>>>> "Mike" == Mike Kravetz <kr...@us...> writes: Mike> On Fri, Jul 18, 2003 at 06:35:42PM +0200, Erich Focht wrote: >> This patch brings back the per CPU user & system times which one >> was used to see in /proc/PID/cpu with 2.4 kernels. Useful for SMP >> and NUMA scheduler development, needed for reasonable output in >> numabench / numa_test. >> Mike> On a somewhat related note ... Mike> We (Big Blue) have a performance reporting application that Mike> would like to know how long a task sits on a runqueue before it Mike> is actually given the CPU. In other words, it wants to know how Mike> long the 'runnable task' was delayed due to contention for the Mike> CPU(s). Of course, one could get an overall feel for this based Mike> on total runqueue length. However, this app would really like Mike> this info on a per-task basis. Mike> Does anyone else think this type of info would be useful? This is exactly what my microstate accounting patch does. Per task figures for: -- how long on CPU -- how long on active queue -- how long on expired queue -- how long sleeping for paging -- how long sleeping in other non-interruptible state -- how long sleeping interruptibly -- how much time stolen for interrupts -- how long in system call -- how long sleeping on Futex -- how long sleeping for epoll, poll or select I haven't yet added time spent handling traps, so the ONCPU time includes pagefault and other trap time; also I've implemented the low level timers only for X86 and IA64. It'd be pretty trivial to add other architectures. The most recent published version of the patch is at http://www.ussg.iu.edu/hypermail/linux/kernel/0306.3/0636.html (that one doesn't include all the states I mentioned, but the on-queue times *are* counted) There'll be another patch with more states soon. -- Dr Peter Chubb http://www.gelato.unsw.edu.au peterc AT gelato.unsw.edu.au You are lost in a maze of BitKeeper repositories, all slightly different. |