Re: decaying average for %CPU

From: Albert Cahalan (albert_at_users.sf.net)
Date: 10/17/03

  • Next message: Albert Cahalan: "Re: /proc reliability & performance" 
    To: Nick Piggin <piggin@cyberone.com.au>
Date:	17 Oct 2003 00:17:22 -0400

    On Thu, 2003-10-16 at 23:21, Nick Piggin wrote:
    > Albert Cahalan wrote:
    > >On Thu, 2003-10-16 at 22:56, Nick Piggin wrote:
    > >>Albert Cahalan wrote:
    > >>
    > >>>The UNIX standard requires that Linux provide
    > >>>some measure of a process's "recent" CPU usage.
    > >>>Right now, it isn't provided. You might run a
    > >>>CPU hog for a year, stop it ("kill -STOP 42")
    > >>>for a few hours, and see that "ps" is still
    > >>>reporting 99.9% CPU usage. This is because the
    > >>>kernel does not provide a decaying average.
    > >>>
    > >>I think the kernel provides enough info for userspace to do
    > >>the job, doesn't it?
    > >>
    > >
    > >I'm pretty sure not. Linux provides:
    > >
    > >per-process start time
    > >current time
    > >per-process total (lifetime) CPU usage
    > >units of time measurement (awkwardly)
    > >boot time
    >
    > But your userspace program can calculate deltas in the total
    > CPU statistics. Yep, its in /proc/stat.

    Huh?

    This isn't about "top", which displays % of CPU
    time used over the refresh interval by reading
    all the process data multiple times.

    This is about programs like "ps", which read
    everything and then spit out the output.

    I hope you're not suggesting to read things
    twice with a huge sleep(5) in the middle, or
    to run some kind of daemon that polls /proc
    once a second. That's far beyond horrid.

    > >>From that you can compute %CPU over the whole
    > >life of the process. This does not meet the
    > >requirements of the UNIX standard.
    > >
    > >What we do for load average is about right,
    > >except that per-process values can't all get
    > >updated at the same time. So the algorithm
    > >needs to be adjusted a bit to allow for that
    >
    > load average is not CPU load though

    Sure, but the algorithm is pretty close. Put in
    a 1.0 when the CPU is used and a 0.0 when not,
    and you have system-wide %CPU. To make that be
    per-process instead, you need to adjust the
    multiplier to account for a variable amount of
    time since the process last ran. That involves
    fixed-point exponentiation I guess, which might be
    approximated with a polynomial or lookup table.

    You can push the last step (only) out into
    user-space, when the last-computed value is
    adjusted for time spent since there last was
    a state change between running and not. I've
    doubts about this being a good idea though,
    since it gives an ABI that prevents future
    changes to the time constants.

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  • Next message: Albert Cahalan: "Re: /proc reliability & performance"

    Relevant Pages