All of lore.kernel.org
 help / color / mirror / Atom feed
* decaying average for %CPU
@ 2003-10-17  2:35 Albert Cahalan
  2003-10-17  2:56 ` Nick Piggin
  0 siblings, 1 reply; 6+ messages in thread
From: Albert Cahalan @ 2003-10-17  2:35 UTC (permalink / raw)
  To: linux-kernel mailing list

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.

Another OS uses a fixed-point decaying average,
with this sort of representation:
0x8000 is 100%
0x2000 is 25%
0x0000 is 0%

Anybody have a version of the algorithm that...

* works with traditional 100 HZ ticks
* works with exact (TSC-based) accounting
* lets a thread-group sum to well over 100%
* doesn't require updates to idle processes

???

I'm thinking it would be nice to have the
binary point be between a pair of 32-bit ints.
That might allow for great range w/o doing
lots of "long long" operations, but I haven't
worked out the details.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: decaying average for %CPU
  2003-10-17  2:35 decaying average for %CPU Albert Cahalan
@ 2003-10-17  2:56 ` Nick Piggin
  2003-10-17  3:00   ` Albert Cahalan
  0 siblings, 1 reply; 6+ messages in thread
From: Nick Piggin @ 2003-10-17  2:56 UTC (permalink / raw)
  To: Albert Cahalan; +Cc: linux-kernel mailing list



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?



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: decaying average for %CPU
  2003-10-17  2:56 ` Nick Piggin
@ 2003-10-17  3:00   ` Albert Cahalan
  2003-10-17  3:21     ` Nick Piggin
  0 siblings, 1 reply; 6+ messages in thread
From: Albert Cahalan @ 2003-10-17  3:00 UTC (permalink / raw)
  To: Nick Piggin; +Cc: Albert Cahalan, linux-kernel mailing list

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

>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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: decaying average for %CPU
  2003-10-17  3:00   ` Albert Cahalan
@ 2003-10-17  3:21     ` Nick Piggin
  2003-10-17  4:17       ` Albert Cahalan
  0 siblings, 1 reply; 6+ messages in thread
From: Nick Piggin @ 2003-10-17  3:21 UTC (permalink / raw)
  To: Albert Cahalan; +Cc: linux-kernel mailing list



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.

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



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: decaying average for %CPU
  2003-10-17  3:21     ` Nick Piggin
@ 2003-10-17  4:17       ` Albert Cahalan
  2003-10-17 22:48         ` Nick Piggin
  0 siblings, 1 reply; 6+ messages in thread
From: Albert Cahalan @ 2003-10-17  4:17 UTC (permalink / raw)
  To: Nick Piggin; +Cc: Albert Cahalan, linux-kernel mailing list

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.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: decaying average for %CPU
  2003-10-17  4:17       ` Albert Cahalan
@ 2003-10-17 22:48         ` Nick Piggin
  0 siblings, 0 replies; 6+ messages in thread
From: Nick Piggin @ 2003-10-17 22:48 UTC (permalink / raw)
  To: Albert Cahalan; +Cc: linux-kernel mailing list




Albert Cahalan wrote:

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

Yeah I spose it is.



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2003-10-17 22:48 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2003-10-17  2:35 decaying average for %CPU Albert Cahalan
2003-10-17  2:56 ` Nick Piggin
2003-10-17  3:00   ` Albert Cahalan
2003-10-17  3:21     ` Nick Piggin
2003-10-17  4:17       ` Albert Cahalan
2003-10-17 22:48         ` Nick Piggin

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.