From: Keir Fraser <keir.fraser@eu.citrix.com>
To: Dulloor <dulloor@gmail.com>
Cc: Andre Przywara <andre.przywara@amd.com>,
Dan Magenheimer <dan.magenheimer@oracle.com>,
"xen-devel@lists.xensource.com" <xen-devel@lists.xensource.com>,
George Dunlap <George.Dunlap@eu.citrix.com>,
Ian Pratt <Ian.Pratt@eu.citrix.com>,
Papagiannis Anastasios <apapag@ics.forth.gr>
Subject: Re: [PATCH]pcpu tuples [was Re: [Xen-devel] Xen 3.4.1 NUMA support]
Date: Tue, 17 Nov 2009 07:21:51 +0000 [thread overview]
Message-ID: <C727FF8F.C06B%keir.fraser@eu.citrix.com> (raw)
In-Reply-To: <940bcfd20911162256u76fe97d4h647284570066d6a@mail.gmail.com>
I think this is good. However, the socket and node ids can be fairly
arbitrary small numbers -- we need a way for the admin to find out the
topology and 'addresses' of physical cpus via xm. Perhaps a new 'xm
cpu-list' command to basically dump the pcpu_tuple information in ascending
order of node, then socket, then core, then thread, with one row per cpu:
node socket core thread xen-cpu-id
More info could be added beyond these five pieces of information, as we
later see fit.
An alternative would be to rename the socket/node identifiers in
pyxc_physinfo, or even in Xen itself, to achieve contiguity. However I think
a cpu-list command would still be useful, and it's easy to implement.
-- Keir
On 17/11/2009 06:56, "Dulloor" <dulloor@gmail.com> wrote:
> Attached is a patch to construct pcpu tuples of the form
> (node.socket.core.thread), and (currently)used by xm vcpu-pin utility.
>
> -dulloor
>
> On Fri, Nov 13, 2009 at 11:02 AM, Keir Fraser <keir.fraser@eu.citrix.com>
> wrote:
>> On 13/11/2009 15:40, "Ian Pratt" <Ian.Pratt@eu.citrix.com> wrote:
>>
>>>> Even better would be to have pCPUs addressable and listable explicitly as
>>>> dotted tuples. That can be implemented entirely within the toolstack, and
>>>> could even allow wildcarding of tuple components to efficiently express
>>>> cpumasks.
>>>
>>> Yes, I'd certainly like to see the toolstack support dotted tuple notation.
>>>
>>> However, I just don't trust the toolstack to get this right unless xen has
>>> already set it up nicely for it with a sensible enumeration and defined
>>> sockets-per-node, cores-per-socket and threads-per-core parameters. Xen
>>> should
>>> provide a clean interface to the toolstack in this respect.
>>
>> Xen provides a topology-interrogation hypercall which should suffice for
>> tools to build up a {node,socket,core,thread}<->cpuid mapping table.
>>
>> -- Keir
>>
>>
>>
>> _______________________________________________
>> Xen-devel mailing list
>> Xen-devel@lists.xensource.com
>> http://lists.xensource.com/xen-devel
>>
next prev parent reply other threads:[~2009-11-17 7:21 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-11-17 6:56 [PATCH]pcpu tuples [was Re: [Xen-devel] Xen 3.4.1 NUMA support] Dulloor
2009-11-17 7:21 ` Keir Fraser [this message]
2009-11-24 5:51 ` Jiang, Yunhong
2009-11-19 9:05 ` Andre Przywara
2009-11-19 9:33 ` Jan Beulich
2009-11-19 15:33 ` Dan Magenheimer
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=C727FF8F.C06B%keir.fraser@eu.citrix.com \
--to=keir.fraser@eu.citrix.com \
--cc=George.Dunlap@eu.citrix.com \
--cc=Ian.Pratt@eu.citrix.com \
--cc=andre.przywara@amd.com \
--cc=apapag@ics.forth.gr \
--cc=dan.magenheimer@oracle.com \
--cc=dulloor@gmail.com \
--cc=xen-devel@lists.xensource.com \
/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.