From: Heiko Carstens <heiko.carstens@de.ibm.com>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org, Heiko Carstens <heiko.carstens@de.ibm.com>
Subject: [patch 2/8] [PATCH] lscpu: fix cpu map array sizes
Date: Wed, 10 Aug 2011 10:36:47 +0200 [thread overview]
Message-ID: <20110810083823.094548131@de.ibm.com> (raw)
In-Reply-To: 20110810083645.135814950@de.ibm.com
From: Heiko Carstens <heiko.carstens@de.ibm.com>
Completely virtualized architectures like s390 may have multiple
virtual sockets and/or cores where each of them has a different
number of cores and cpus.
So the general assumption within the allocation scheme that e.g.
each socket contains the same number of cores is not necessarily
true. To make sure the arrays are always large enough we simply
allocate enough memory so that each array could hold cpu masks
for all present cpus.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
---
sys-utils/lscpu.c | 13 +++++++++----
1 file changed, 9 insertions(+), 4 deletions(-)
--- a/sys-utils/lscpu.c
+++ b/sys-utils/lscpu.c
@@ -660,11 +660,16 @@ read_topology(struct lscpu_desc *desc, i
*/
if (!desc->nthreads)
desc->nthreads = nsockets * ncores * nthreads;
+ /* For each map we make sure that it can have up to ncpus
+ * entries. This is because we cannot reliably calculate the
+ * number of cores, sockets and books on all architectures.
+ * E.g. completely virtualized architectures like s390 may
+ * have multiple sockets of different sizes.
+ */
+ desc->coremaps = xcalloc(desc->ncpus, sizeof(cpu_set_t *));
+ desc->socketmaps = xcalloc(desc->ncpus, sizeof(cpu_set_t *));
if (book_siblings)
- desc->bookmaps = xcalloc(nbooks, sizeof(cpu_set_t *));
-
- desc->socketmaps = xcalloc(nsockets, sizeof(cpu_set_t *));
- desc->coremaps = xcalloc(ncores * nsockets, sizeof(cpu_set_t *));
+ desc->bookmaps = xcalloc(desc->ncpus, sizeof(cpu_set_t *));
}
add_cpuset_to_array(desc->socketmaps, &desc->nsockets, core_siblings);
next prev parent reply other threads:[~2011-08-10 8:36 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-08-10 8:36 [patch 0/8] various lscpu patches Heiko Carstens
2011-08-10 8:36 ` [patch 1/8] [PATCH] lscpu: fix s390 bogomips detection coding style Heiko Carstens
2011-08-10 8:36 ` Heiko Carstens [this message]
2011-08-10 8:36 ` [patch 3/8] [PATCH] lscpu: fix fallback nthreads calculation Heiko Carstens
2011-08-10 8:36 ` [patch 4/8] [PATCH] lscpu: detect IBM hypervisor Heiko Carstens
2011-08-10 8:36 ` [patch 5/8] [PATCH] lscpu: use hypervisor generated topology information Heiko Carstens
2011-08-10 8:36 ` [patch 6/8] [PATCH] lscpu: show dispatching mode Heiko Carstens
2011-08-10 8:36 ` [patch 7/8] [PATCH] lscpu: add cpu polarization to parseable output Heiko Carstens
2011-08-10 8:36 ` [patch 8/8] [PATCH] lscpu: add physical cpu address " Heiko Carstens
2011-08-15 8:45 ` [patch 0/8] various lscpu patches Heiko Carstens
2011-08-15 9:24 ` Karel Zak
2011-08-30 10:12 ` Karel Zak
2011-08-30 11:18 ` Heiko Carstens
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20110810083823.094548131@de.ibm.com \
--to=heiko.carstens@de.ibm.com \
--cc=kzak@redhat.com \
--cc=util-linux@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).