libgtop2 used by system monitor reporting incorrect number of processors for Ubuntu 13.10 vms on Hyper-V

Bug #1210280 reported by Abhishek Gupta on 2013-08-08
This bug affects 2 people
Affects Status Importance Assigned to Milestone
libgtop2 (Ubuntu)

Bug Description

We have noticed that when a Ubuntu 13.10 VM is configured with 64CPUs on Hyper-V, system monitor only shows 32 CPUs. This bug is also observed on Ubuntu 12.04. So it seems like an old issue. Please provide a fix.

Attached are two files - One of the files is the output from system monitor and the other one contains the output from lscpu. System monitor output shows 32 CPUs whereas lscpu output shows the 64 CPUs correctly.

Please let me know if you need more info.


Abhishek Gupta (abgupta) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit and add the package name in the text box next to the word Package.

[This is an automated message. I apologize if it reached you inappropriately; please just reply to this message indicating so.]

tags: added: bot-comment
Changed in lansing:
assignee: nobody → David Medberry (med)
importance: Undecided → High
David Medberry (med) wrote :

This appears to be a setting in glibtop/cpu.h: which becomes an array size and only GLIBTOP_NCPU are gathered.

From the source package: libgtop2:

cat -n
    53 /* Nobody should really be using more than 4 processors.
    54 Yes we are :)
    55 Nobody should really be using more than 32 processors.
    56 */
    57 #define GLIBTOP_NCPU 32
    59 typedef struct _glibtop_cpu glibtop_cpu;
    61 struct _glibtop_cpu
    62 {
    63 guint64 flags;
    64 guint64 total; /* GLIBTOP_CPU_TOTAL */
    65 guint64 user; /* GLIBTOP_CPU_USER */
    66 guint64 nice; /* GLIBTOP_CPU_NICE */
    67 guint64 sys; /* GLIBTOP_CPU_SYS */
    68 guint64 idle; /* GLIBTOP_CPU_IDLE */
    69 guint64 iowait; /* GLIBTOP_CPU_IOWAIT */
    70 guint64 irq; /* GLIBTOP_CPU_IRQ */
    71 guint64 softirq; /* GLIBTOP_CPU_SOFTIRQ */
    72 guint64 frequency; /* GLIBTOP_CPU_FREQUENCY */
    73 guint64 xcpu_total [GLIBTOP_NCPU]; /* GLIBTOP_XCPU_TOTAL */
    74 guint64 xcpu_user [GLIBTOP_NCPU]; /* GLIBTOP_XCPU_USER */
    75 guint64 xcpu_nice [GLIBTOP_NCPU]; /* GLIBTOP_XCPU_NICE */
    76 guint64 xcpu_sys [GLIBTOP_NCPU]; /* GLIBTOP_XCPU_SYS */
    77 guint64 xcpu_idle [GLIBTOP_NCPU]; /* GLIBTOP_XCPU_IDLE */
    78 guint64 xcpu_iowait [GLIBTOP_NCPU]; /* GLIBTOP_XCPU_IOWAIT */
    79 guint64 xcpu_irq [GLIBTOP_NCPU]; /* GLIBTOP_XCPU_IRQ */
    80 guint64 xcpu_softirq [GLIBTOP_NCPU]; /* GLIBTOP_XCPU_SOFTIRQ */
    81 guint64 xcpu_flags; /* GLIBTOP_XCPU_IDLE */
    82 };

So, in short, System Monitor is not designed to be the official reference for CPU counts.
I've filed a bug against the Ubuntu/Debian package.
Running gnome on a 64 core machine is a bit odd--they are typically used as headless servers.

David Medberry (med) wrote :

Adding appopriate source package, libgtop2

affects: ubuntu → libgtop2 (Ubuntu)
David Medberry (med) wrote :

Currently Ubuntu supports 256 CPUs in a server config (ref: and that # is still valid for Saucy.

David Medberry (med) on 2013-08-13
summary: - System monitor reporting incorrect number of processors for Ubuntu 13.10
- vms on Hyper-V
+ libgtop2 used by system monitor reporting incorrect number of processors
+ for Ubuntu 13.10 vms on Hyper-V
David Medberry (med) wrote :
Changed in lansing:
milestone: none → ubuntu-13.08.31

The attachment "Change GLIBTOP_NCPU from 32 to 256" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

tags: added: patch
Changed in libgtop2 (Ubuntu):
status: New → Triaged
importance: Undecided → Medium
Marc Deslauriers (mdeslaur) wrote :

Thanks for the debdiff, but:

1- Won't changing GLIBTOP_NCPU break ABI, and require a bunch of other packages to be rebuilt?
2- Won't increasing GLIBTOP_NCPU dramatically increase memory consumption?

Changed in libgtop2 (Ubuntu Saucy):
status: Triaged → Incomplete
David Medberry (med) wrote :


I didn't see that GLIBTOP_NCPU was used anywhere else. I'll dig some more.
Yes, it will dramatically increase memory consumption in some tools.

David Medberry (med) on 2013-08-19
Changed in lansing:
status: New → Confirmed
Changed in libgtop:
importance: Unknown → Wishlist
status: Unknown → Confirmed
David Medberry (med) wrote :

Apparently SuSE has patched there version (and is likely that disconnect is what triggered the initial customer concern.)

Martin Pitt (pitti) wrote :

Note that this patch breaks the ABI according to upstream, so this needs to go along with a SONAME bump and a library transition. Bumping the SONAME in a distro specific patch is absolutely nothing that we want to do, so this ought to be applied/fixed upstream, SONAME bumped there, and released as a new upstream version.

Hence, unsubscribing sponsors. Thanks!

David Medberry (med) on 2013-08-27
Changed in lansing:
status: Confirmed → Won't Fix
no longer affects: lansing
Robert Ancell (robert-ancell) wrote :

I incorrectly marked libgtop2 as fixing this bug. I doesn't so please mark it back from Fix Committed when that version lands.

Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libgtop2 -

libgtop2 ( utopic; urgency=medium

  * New upstream release
    - Increases maximum CPU limit (LP: #1210280)
  * debian/control:
  * debian/rules:
  * debian/libgtop2-10.install
  * debian/libgtop2-10.symbols
    - Update soname
  * debian/patches/06_kfreebsd_sys_pipe.patch:
    - Applied upstream
 -- Robert Ancell <email address hidden> Tue, 19 Aug 2014 09:13:36 +1200

Changed in libgtop2 (Ubuntu):
status: Incomplete → Fix Released
Changed in libgtop2 (Ubuntu):
status: Fix Released → Incomplete
Rolf Leggewie (r0lf) wrote :

saucy has seen the end of its life and is no longer receiving any updates. Marking the saucy task for this ticket as "Won't Fix".

Changed in libgtop2 (Ubuntu Saucy):
status: Incomplete → Won't Fix
Geokimbo (kfrankcombe) wrote :

This is still an issue for 16.04 and an 80 "core" system. SysInfo only shows 72 cores while lscpu shows 80. As an aside the layout of the SysInfo GUI could do with a workover. For 4 CPUs it is fine but after that it starts to get very red. I have 3 machines with dual hexacores and 2 machines with quad decacores all hyperthreaded and all running 16.04 as workstations to do crunching. In SysInfo on the quad decacore machines the CPU usage graph is ~8mm high and all I can see is red. Allowing components of the performance display to be rescaled and to distribute the rainbow more evenly from CPU#1 to CPU#n would be a worthwhile improvement. The comments in libgtop3 before defining GLIBTOP_NCPU sound like you don't think we should be using Ubuntu for real work - use the RH/SUSE lineage instead - not all of us are gamers using domestic machines;-)

Jeremy Bicha (jbicha) wrote :

libgtop2 2.32.0 included in Ubuntu 16.04 LTS has bumped the CPU number limit to 1024.

Therefore, I'm closing this bug since that is more than this bug originally asked for and I'm skeptical whether tools using libgtop2 can adequately work with more than 1024 CPUs anyway.

Changed in libgtop2 (Ubuntu):
status: Incomplete → Fix Released
Changed in libgtop:
status: Confirmed → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.