From: Brice Goglin <Brice.Goglin@inria.fr>
To: linux-numa@vger.kernel.org
Subject: bitmask/nodemask strangeness with sparse node ids
Date: Mon, 20 Feb 2012 15:18:28 +0100 [thread overview]
Message-ID: <4F425634.30203@inria.fr> (raw)
Hello,
I am debugging some problems on a strange power7 virtual node that
contains 3 sparse-numbered NUMA nodes:
* node#0 has NO memory but many CPUs
* node#2 and #3 have memory but no CPUs
I am trying to understand what numa_all_nodes_ptr and friends are
supposed to contain. I see:
numa_all_nodes_ptr = bits 2 & 3
This seems to match the manpage when it says "representing all nodes on
which the calling task may allocate memory". But it doesn't really match
when it says "a bit mask that has all available nodes set" above (should
be bits 0&2&3).
If I look at numa_all_nodes instead, I get bits 0 & 1. libnuma.c seems
to set as many first bits as there are nodes I can allocate from. But I
don't see anywhere in the code something that can deal with such
nodemask on sparse-numbered platforms. For instance,
copy_bitmask_to_nodemask(numa_all_nodes_ptr, foo) puts bits 2 & 3 in foo
while foo should be equal to numa_all_nodes.
So:
* is the nodemask API known to be broken when node ids are sparse?
* is the nodemask API officially deprecated? If so, could this be
clarified in the header and manpage? The definition of nodemask_t is
very close to the header of numa.h without anything saying "don't use it".
I actually think that everything nodemask_t related should be out of
numa.h and out of the manpage. If people should not use them, they
should be hidden. It could be moved in something like numacompat1.h for
instance. Right now, things are very confusing (especially when one
finds numa_allocate_nodemask() which returns a bitmask :))
Thanks
Brice Goglin
reply other threads:[~2012-02-20 14:18 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=4F425634.30203@inria.fr \
--to=brice.goglin@inria.fr \
--cc=linux-numa@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).