On Apr 27, 2007, at 9:58 AM, Bert Wesarg wrote:
> A little picture, a xeon processor with one core and hyperthreading
> enabled:
>
> +------------------------+
> | Xeon |
> |phys_id = 0 core_id = 0 |
> +------------------------+
> / \
> +----------+ +----------+
> | thread | | thread |
> | siblings | | siblings |
> | 00000003 | | 00000003 |
> +----------+ +----------+
> | |
> cpu0 cpu1
By "cpu0" and "cpu1", I assume you mean linux virtual processor ID.
> from this I would build the following mapping:
>
> cpu0 <-> (0,0,0)
> cpu1 <-> (0,0,1)
>
> because cpu0 has zero bits set before bit 0 in the thread_siblings
> cpumap
> because cpu1 has one bit set before bit 1 in the thread_siblings
> cpumap
Ok.
> Your old mappings with thread:
> - one-to-one: (socket,core,thread) -> processor ID
> - one-to-one: (socket,core,thread) -> node ID
> - one-to-one: processor ID -> (socket,core,thread)
> - one-to-one: processor ID -> node ID
> - one-to-many: node ID -> (socket,core,thread)
> - one-to-many: node ID -> processor ID
>
> My opinion:
>
> (1) one-to-one: (socket,core,thread) <-> processor ID
>
> (2a) one-to-one: processor ID -> node ID
> (2b) one-to-many: node ID -> processor ID
So I'm confused -- my list was simply all the data relationships, not
a proposal for the functions / actions / lookups. I agree that
putting the thread in the tuple makes the list shorter, but why did
you remove the node ID <--> (socket,core,thread) relationship from
your second list?
More specifically, what is your second list as compared to your first
list?
>> /* ...and so on */
> This approach looks like an higher level abstraction to the lower
> level
> mapping.
Well, yes. As is any API we put on top of the data in /sys. :-)
Can you list some prototypes for functions that you're proposing?
--
Jeff Squyres
Cisco Systems
|
![[Flag]](../../../../../community/mirrors/flag-us.gif){kind=small}