All of
 help / color / mirror / Atom feed
From: Peter Chubb <>
To: Mike Kravetz <>
Cc: Erich Focht <>,
	LSE <>,
	linux-kernel <>
Subject: Re: [Lse-tech] [patch 2.6.0-test1] per cpu times
Date: Mon, 21 Jul 2003 14:47:45 +1000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

>>>>> "Mike" == Mike Kravetz <> 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 
(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  peterc AT
You are lost in a maze of BitKeeper repositories,   all slightly different.

  parent reply	other threads:[~2003-07-21  4:33 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-07-18 16:35 [patch 2.6.0-test1] per cpu times Erich Focht
2003-07-18 18:18 ` [Lse-tech] " Mike Kravetz
2003-07-18 19:57   ` William Lee Irwin III
2003-07-18 20:53     ` Rick Lindsley
2003-07-21  4:47   ` Peter Chubb [this message]
2003-07-23 21:50   ` bill davidsen
2003-07-23 23:32     ` Peter Chubb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.