[DragonFlyBSD - Bug #2447] TOP isn't reporting correctly CPU states without -M
Chris Turner via Redmine
bugtracker-admin at leaf.dragonflybsd.org
Thu Nov 15 05:52:46 PST 2012
Issue #2447 has been updated by Chris Turner.
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.
Bug #2447: TOP isn't reporting correctly CPU states without -M
Author: Charles Rapenne
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
You have received this notification because you have either subscribed to it, or are involved in it.
To change your notification preferences, please click here: http://bugs.dragonflybsd.org/my/account
More information about the Bugs