[lkml]   [2001]   [Jun]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
Subjectre: accounting for threads
"J . A . Magallon" <> wrote:
> I want to know the CPU time used by a POSIX-threaded program. I have tried
> to use getrusage() with RUSAGE_SELF and RUSAGE_CHILDREN. Problem:
> main thread just do nothing, spawns children and waits. And I get always
> 0 ru_utime.
> I guess it can be because of 2 things:
> - RUSAGE_CHILDREN only works for fork()'ed children (although in linux threads
> and processes are the same). Perhaps fork() sets some kind of flag in
> clone() for accounting.
> - AFAIK, linux puts an intermediate 'thread controller'. That controller
> uses no CPU time, and RUSAGE_CHILDREN gets only the first children level.
> Any suggestion to mesaure threads CPU time ? I can't manage only with
> wall-time, because I'm not sure to have all the box just for me.
> And I would like also to mesaure system time to evaluate contention.

My post you replied to yesterday, subject "Re: getrusage vs /proc/pid/stat",
contains code that does what you want (it's also at
To use it, declare a variable
LinuxTimes lt;
have each thread call lt.addSelf() once; then to measure the total CPU time
used by all those threads as a group, call lt.times() instead of times().
(On Solaris, you can continue to just call times(), you don't need lt at all.)
lt.times() is a simulation of the classical times() system call for LinuxThreads.

Let me know if this helps. And anyone else, let me know if there's a simpler
way to do this. Should LinuxThreads be doing this under the hood, so it can
be a little closer to posix threads compliance?
- Dan

"A computer is a state machine.
Threads are for people who can't program state machines."
- Alan Cox
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:55    [W:0.136 / U:1.828 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site