From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Samuel Thibault <samuel.thibault@ens-lyon.org>,
Xen-devel List <xen-devel@lists.xen.org>
Subject: Re: Hwloc with Xen host topology
Date: Thu, 2 Jan 2014 22:01:30 +0000 [thread overview]
Message-ID: <52C5E1BA.6070501@citrix.com> (raw)
In-Reply-To: <20140102215554.GX29132@type.youpi.perso.aquilenet.fr>
On 02/01/14 21:55, Samuel Thibault wrote:
> Andrew Cooper, le Thu 02 Jan 2014 21:50:06 +0000, a écrit :
>> On 02/01/14 21:24, Samuel Thibault wrote:
>>> Andrew Cooper, le Thu 02 Jan 2014 20:26:49 +0000, a écrit :
>>>> Cores are numbered per-socket in Xen, while sockets,
>>>> numa nodes and cpus are numbered on an absolute scale. There is
>>>> currently a gross hack in my hwloc code which adds (socket_id *
>>>> cores_per_socket * threads_per_core) onto each core id to make them
>>>> similarly numbered on an absolute scale. This is fine for a homogeneous
>>>> system, but not for a hetrogeneous system.
>>> BTW, hwloc does not need these physical ids to be unique, it can cope
>>> with duplication and whatnot. That said, having a coherent interface at
>>> the Xen layer would be a good thing, indeed :)
>> If I take out the described hack, I am presented with
>>
>> ****************************************************************************
>> * hwloc has encountered what looks like an error from the operating system.
>> *
>> * object (Core P#0 cpuset 0x30000003) intersection without inclusion!
>> * Error occurred in topology.c line 853
>> *
>> * Please report this error message to the hwloc user's mailing list,
>> * along with the output from the hwloc-gather-topology.sh script.
>> ****************************************************************************
>>
>> Which I took to mean "I have done something stupid". I looked and saw
>> that I was attempting to insert a second Core P#0 object with a
>> different cpuset and decided to renumber the cores so they didn't
>> overlap in physical ids.
>>
>> If you believe that this should indeed work, then I guess I need to
>> raise a bug...
> Well, logical processor physical ids, i.e. what is used for indexing
> physical cpusets, have to be unique. The core/socket/node IDs don't have
> to.
>
> Samuel
Then a bug needs raising. My hack only changes the Core physical ID as
far as hwloc is concerned. The PU physical IDs are unchanged by the
hack, and already unique as presented by Xen.
~Andrew
next prev parent reply other threads:[~2014-01-02 22:01 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-02 20:26 Hwloc with Xen host topology Andrew Cooper
2014-01-02 21:24 ` Samuel Thibault
2014-01-02 21:50 ` Andrew Cooper
2014-01-02 21:55 ` Samuel Thibault
2014-01-02 22:01 ` Andrew Cooper [this message]
2014-01-02 22:04 ` Samuel Thibault
2014-01-02 21:38 ` Andrew Cooper
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=52C5E1BA.6070501@citrix.com \
--to=andrew.cooper3@citrix.com \
--cc=samuel.thibault@ens-lyon.org \
--cc=xen-devel@lists.xen.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.