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

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 https://wiki.ubuntu.com/Bugs/FindRightPackage. 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 https://bugs.launchpad.net/ubuntu/+bug/1210280/+editstatus 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.]

This appears to be a setting in glibtop/cpu.h:

https://developer.gnome.org/libgtop/stable/libgtop-cpu.html#GLIBTOP-NCPU:CAPS 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
    58
    59 typedef struct _glibtop_cpu glibtop_cpu;
    60
    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 };
    83
...

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.

Adding appopriate source package, libgtop2

Currently Ubuntu supports 256 CPUs in a server config (ref: http://askubuntu.com/questions/158555/how-many-maximum-cpus-does-ubuntu-support-by-default) and that # is still valid for Saucy.

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

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?

Marc,

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.

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

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!

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

This bug was fixed in the package libgtop2 - 2.30.0.is.2.30.0-0ubuntu1

---------------
libgtop2 (2.30.0.is.2.30.0-0ubuntu1) 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

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

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

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.