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 -~----------~----~----~----~------~----~------~--~---
