Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

djberg96 (2603)

djberg96
  (email not shown publicly)

Journal of djberg96 (2603)

Tuesday November 12, 2002
09:36 AM

top spin

[ #8899 ]
Yet more time spent on top last night. I'm down to figuring out how cpu time per process is calculated. Searching Google proved fruitless, as everyone spouts off "getrusage", "clock" or "times(2)" in response to this question, none of which can get cpu time for an arbitrary pid - they can only get their own process info (or their children's). The fine folks of IRC were unable to help, either.

I'm sure it's some stime or utime calculation, but I haven't determined what it is yet, as none of my guesses seemed to work out to a meaningful value.

In better news, the Packers are absolutely crushing everyone in their path. I'm giddy.

UPDATE: The formula is (utime + stime) / CLK_TCK, rounded up (at least, as far as I can tell).


List all Journal entries
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

top spin 5 Comments More | Login | Reply /

 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • There are two ways to get access to the info that top(1) has. The first is to scruffle through /proc, which has always seemed a waste of time to me--between getting a list of files and processing them all, things have changed. The second is to use the kvm_*() system calls and scruffle through the kernel's process table yourself. This is what top does, and it's also subject to the problem that it takes more than one tick for you to do all the scruffling, so the information you're working with is always ou
    • The first is to scruffle through /proc, which has always seemed a waste of time to me--between getting a list of files and processing them all, things have changed. The second is to use the kvm_*() system calls

      I'm not sure my pea-brain could handle the kvm api, though to be honest I haven't looked - just heard it was tough. I also thought it was a Solaris-only thing. Guess not. I'm also not sure I want the "more than one tick" issue. For now I can live with data that's .05 seconds out of date.

      It's

      • One very nice trick I learned from Dan Urist's Proc::ProcessTable module was to create separate source files for each platform, and simply link to the appropriate one

        The danger to this approach is that many of the platforms will have code that is almost the same, differing only in a few details. When you fix a bug in that mostly common code in one, it is easy to forget to fix the same bug in the others because they have separate copies of the (almost) identical code. You can have the same problem with I

        • The danger to this approach is that many of the platforms will have code that is almost the same, differing only in a few details. When you fix a bug in that mostly common code in one, it is easy to forget to fix the same bug in the others because they have separate copies of the (almost) identical code.

          Ah, but if the code's nearly identical, then it becomes a matter of copy/paste anyway. Fix one, and you know how to fix the rest. Sure, it'll be a little more time, but not that much more time. It would

          • The keyword there was forget. It's not hard to make a cut and paste common change, as long as you remember to look in all the places that share the code.

            My roommate at University made up a law "If there is more than one copy of something, at most one of them is correct." with the addendum that "The number that are correct approachs zero asymptotically over time."

            It is harder to forget to check the other variants when they are in the same file (even then, it is still possible to forget to check them [al

Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.