Bug #2447

TOP isn't reporting correctly CPU states without -M

Added by charles.rapenne over 1 year ago. Updated about 1 year ago.

Status:ResolvedStart date:11/06/2012
Priority:NormalDue date:
Assignee:-% Done:

100%

Category:-
Target version:-

Description

Hello,

The top command isn't reporting the line "CPU states" correctly on my dual core laptop.

With the command "top", if a thread is eating 1 CPU, top reports 0.0% idle and 100% in user, it should displays 50% idle and 50% user
With the command "top -M", if a thread is eating 1 CPU, top reports 0.0% idle and 100% in user on CPU0, and 100.0% idle on CPU1, this is the correct one

On the screenshot attached, on the right you can see top -M and on the left, top. The command without -M seems to show only CPU0

bugtop.png (21 KB) charles.rapenne, 11/06/2012 01:09 AM

0001-refs-2447-TOP-isn-t-reporting-correctly-CPU-states-w.patch Magnifier - Formatted patch (3.14 KB) jalcazar, 01/05/2013 09:03 PM

History

#1 Updated by marino over 1 year ago

If you take "top" to only apply to CPU#1, doesn't the report then seem correct?

Does the manpage say it will average these values across CPUs when "-M" isn't used or are you just assuming it should be doing that?

#2 Updated by c.turner1 over 1 year ago

On 11/15/12 01:34, John Marino via Redmine wrote:
>
> Issue #2447 has been updated by John Marino.
>
>
> If you take "top" to only apply to CPU#1, doesn't the report then seem correct?

Per his description, no,

Because it should be 50/50 (cpu/idle)
instead of 0/100 for cpu0 and 100/0 for cpu1

Only one of his processors is busy - for a total of 50% system-wide usage

> Does the manpage say it will average these values across CPUs when "-M" isn't used or are you just assuming it should be doing that?

The label in the top display says 'states' (plural) - so either it should
be averaging, or we should change the label to say 'cpu0' - which would
be kind of silly - why would you only want to see the 1st processor activity
on an SMP system? e.g. why bother with the effort to only make it worse?

Upstream doesn't appear to have a multi cpu option, at least per the page
on unixtop.org - I don't have a Free/Net set of systems around to
review w/r/t to their behavior - per manpage similarities, openbsd appears
to default to multicpu, with a '-1' flag to force combined statistics,
but my sole openbsd machine is uniproc so not sure if this is accurate.

I'll try to noodle with this this weekend if noone gets to it by then.

Cheers,

- Chris

#3 Updated by c.turner1 over 1 year ago

On 11/15/12 07:52, Chris Turner via Redmine wrote:
> The label in the top display says 'states' (plural) -

Well - this was me reading it wrong - since 'states'
is what is said for multi CPU as well - states
looks to refer to e.g. user/system/idle 'states'.

But anyhow - an average would be better.

Will take a crack at it unless someone beats
me to it.

Cheers,

- Chris

#4 Updated by jalcazar over 1 year ago

  • File 0001-refs-2247-TOP-isn-t-reporting-correctly-CPU-states-w.patch added

This is a bug.
The problem is that when the machine has more than one CPU and the switch M is not used, top only reports the states of the first CPU.

The manual says:

The next line displays a percentage of time spent in each
of the processor states (typically user, nice, system, idle, and
iowait). These percentages show the processor activity during the time
since the last update. For multi-processor systems, this information
is a summation of time across all processors.
http://leaf.dragonflybsd.org/cgi/web-man?command=top
_______________________________________________

FreeBSD (10-CURRENT) and Linux (Ubuntu-11.04) report the overall load.
By default OpenBSD(5.1) displays each processor separately, with -1 shows combined output too (all CPUs).

And I also agree with Chris Turner:
>But anyhow - an average would be better.
So I am attaching a patch that seems to work showing the averages.

#5 Updated by jalcazar over 1 year ago

  • File deleted (0001-refs-2247-TOP-isn-t-reporting-correctly-CPU-states-w.patch)

#7 Updated by ftigeot about 1 year ago

  • Status changed from New to Resolved
  • % Done changed from 0 to 100

Thanks for your patch, a slightly modified version has been pushed to -master.

Also available in: Atom PDF