Date: Wed, 13 Jun 2007 10:23:15 +0200 From: Olivier Certner <olivier.freebsduser@free.fr> To: freebsd-arch@freebsd.org Subject: How to allow userland to access per-thread CPU time information? Message-ID: <200706131023.15778.olivier.freebsduser@free.fr>
next in thread | raw e-mail | index | archive | help
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Hi all,
In the emulator project I work on currently, I need to know the time CPUs=
=20
have spent executing a particular thread of the current process. Basically,=
=20
this is the same functionality (actually, a subset) as provided by=20
getrusage(), except I would want it at the thread-level granularity. In the=
=20
rusage structure, I'm mostly interested by the ru_{u,s}time fields.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0I've looked around for seve=
ral solutions. The POSIX threads interface=20
doesn't seem to define any time reporting function. In FreeBSD, no=20
non-portable extension to this interface provides the functionality. Inside=
=20
the kernel (I'm speaking about RELENG_6 in the following), the thread=20
structure has fields to keep track of the CPU usage (td_{s,uu,us}ticks). I=
=20
agree one such structure represents a KSE context, not exactly a "thread" a=
s=20
seen from userland. But the KSE system seems to provide a solution because =
it=20
defines different mailboxes for userland threads, each having accounting=20
fields (tm_{u,s}ticks).
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0So, the only thing I seem t=
o miss here is some support to retrieve=20
this information from the threading library. Hence my questions: does anyon=
e=20
have begun to work on such a functionality? If not, are you aware of any=20
attempt of standardizing such an access? I would be glad to help design=20
and/or implement this functionality in FreeBSD's threading libraries.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0For completeness, I've also=
investigated the values that the "who"=20
parameter of getrusage can take in several OSes, because some of the latter=
=20
use it as a way to return per-thread statistics. It seems that only a few o=
f=20
them implement other values than RUSAGE_SELF and RUSAGE_CHILDREN. Some (suc=
h=20
as Solaris or, since recently, Linux) support the RUSAGE_THREAD value. I=20
don't think there is (and will be one day) consensus on whether the N:M=20
threading model is definitely inferior to the 1:1 model (even in CURRENT, t=
he=20
old N:M library is still there as libkse, although no more the default), so=
,=20
at the moment, I don't find this solution very elegant, since the kernel is=
=20
not necessarily aware of all userland threads, and if it is, going to the=20
kernel to finally retrieve the information from the userland thread schedul=
er=20
library isn't very efficient. I would suggest rather a (non-?)portable=20
addition to the pthread interface, such as a pthread_getrusage function.
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0There has been a recent dis=
cussion on this topic on the=20
LKML. Here's a link to a message from Ulrich Drepper that goes in the same=
=20
direction:
http://www.opensubscriber.com/message/linux-kernel%40vger.kernel.org/661613=
3.html .=20
Time counters were my primary interest, but more generally, access to a=20
per-thread ressource usage report seems desirable. So far, I've not looked =
in=20
detail which rusage structure fields would be relevant for threads.
Any directions or thoughts?
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Regards,
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0Olivier
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200706131023.15778.olivier.freebsduser>