Did you consider having an IPC message to ask the sub-processes for their getrusage(RUSAGE_SELF, *) results?
-scott On Thu, Sep 17, 2009 at 4:06 PM, Evan Martin <[email protected]> wrote: > > For the task manager we want to show CPU usage. Here's a summary of options. > > 1) Use libgtop, which was designed for this. But nixed because it's > GPL, explicitly to prevent apps like us from using it. Bummer. > > 2) Parse the output of "ps". But this only shows cumulative stats, > and the resolution of its output (minutes:seconds) isn't enough to > show data at the resolution we want. > > 3) Extract it ourselves from /proc. Yucky and Linux-specific, but so > it goes. With a lot of advice from Markus and the "top" source code, > I think I can do the following. (The actual code involved in the > various processes described below is actually rather complicated due > to the variety of systems and kernel/glibc/etc. versions they support; > we only care about relatively new (e.g. Linux >=2.6) systems so it's > simplified.) > > /proc/<pid>/task/ contains all threads under a given process. > From each of those, "stat" contains utime and stime numbers, which are > measured in jiffies (ticks). We can sum all these to compute total > ticks for a process. > To convert from ticks to time, multiply by the system hertz. It > appears in the ELF notes in /proc/<pid>/auxv among other places, but > from grepping the glibc source it looks like sysconf(_SC_CLK_TCK) > gives you the same number. (See PS below about "system hertz" in the > presence of tickless.) > > From time per process, we divide by the update rate of the task > manager (along with a factor for the number of CPUs) to show CPU > percentage. > "What could go wrong?" ;) > > If you have any experience on this, like gotchas on certain Linuxes, > input is welcome. I'm reaching around kinda blindly here but > thankfully Markus knows a ton about it. > > > > PS: what about tickless kernels, you ask? Apparently the /proc ticks > are not the same as the kernel ticks. Here's the full amusing comment > from procps. I am proposing on relying on the "recent" behavior from > 2.4 kernels (released in 2001). > > * Some values in /proc are expressed in units of 1/HZ seconds, where HZ > * is the kernel clock tick rate. One of these units is called a jiffy. > * The HZ value used in the kernel may vary according to hacker desire. > * According to Linus Torvalds, this is not true. He considers the values > * in /proc as being in architecture-dependant units that have no relation > * to the kernel clock tick rate. Examination of the kernel source code > * reveals that opinion as wishful thinking. > * > * In any case, we need the HZ constant as used in /proc. (the real HZ value > * may differ, but we don't care) There are several ways we could get HZ: > * > * 1. Include the kernel header file. If it changes, recompile this library. > * 2. Use the sysconf() function. When HZ changes, recompile the C library! > * 3. Ask the kernel. This is obviously correct... > * > * Linus Torvalds won't let us ask the kernel, because he thinks we should > * not know the HZ value. Oh well, we don't have to listen to him. > * Someone smuggled out the HZ value. :-) > * > * This code should work fine, even if Linus fixes the kernel to match his > * stated behavior. The code only fails in case of a partial conversion. > * > * Recent update: on some architectures, the 2.4 kernel provides an > * ELF note to indicate HZ. This may be for ARM or user-mode Linux > * support. This ought to be investigated. Note that sysconf() is still > * unreliable, because it doesn't return an error code when it is > * used with a kernel that doesn't support the ELF note. On some other > * architectures there may be a system call or sysctl() that will work. > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
