RE: [discuss] [PATCH] Export cpu topology for IA32 and x86_64 by sysfs

RE: [discuss] [PATCH] Export cpu topology for IA32 and x86_64 by sysfs

[Pallipadi, Venkatesh]

 

>-----Original Message-----
>From: Andi Kleen [mailto:ak@suse.de] 
>Sent: Tuesday, December 13, 2005 7:51 PM
>To: Zhang, Yanmin
>Cc: linux-kernel@vger.kernel.org; discuss@x86-64.org; 
>Pallipadi, Venkatesh
>Subject: Re: [discuss] [PATCH] Export cpu topology for IA32 
>and x86_64 by sysfs
>
>On Wed, Dec 14, 2005 at 11:11:00AM +0800, Zhang, Yanmin wrote:
>> The patch exports the cpu topology info through sysfs on ia32/x86_64
>> machines. The info is similar to /proc/cpuinfo.
>> 
>> The exported items are:
>> 
>/sys/devices/system/cpu/cpuX/topology/physical_package_id(representing
>> the physical package id of  cpu X)
>> /sys/devices/system/cpu/cpuX/topology/core_id (representing 
>the cpu core
>> id  to cpu X)
>> /sys/devices/system/cpu/cpuX/topology/thread_siblings 
>(representing the
>> thread siblings to cpu X)
>> /sys/devices/system/cpu/cpuX/topology/core_siblings (represeting the
>> core siblings to cpu X)
>
>Hmm, I'm not sure it is that useful. Did someone decide to move
>all information from cpuinfo into sysfs? 
>

Not really. The current display in /proc/cpuinfo, though useful for
human reader,
is not very friendly to scripts. And if one wants to find out which
logical CPUs belong
to the same core, there will have to be some amount of code in userlevel
to parse
the /proc/cpuinfo and get this info. So, we thought that it may be
useful to 
export the masks to the user directly in a genric way. And, while doing
that
thinking was adding new fields in /sysfs rather than /proc/ was better.

Having said that, I feel Nathan's suggestion of doing it in more
architecturally-neutral way should be better than this. We will have a
relook at this one now.

And this needs some documentation changes as well.

Thanks for feedback.
Venki

Re: [discuss] [PATCH] Export cpu topology for IA32 and x86_64 by sysfs

[Andi Kleen]

> Not really. The current display in /proc/cpuinfo, though useful for
> human reader,
> is not very friendly to scripts. And if one wants to find out which
> logical CPUs belong
> to the same core, there will have to be some amount of code in userlevel
> to parse
> the /proc/cpuinfo and get this info. So, we thought that it may be
> useful to 
> export the masks to the user directly in a genric way. And, while doing
> that
> thinking was adding new fields in /sysfs rather than /proc/ was better.

Hmm - having written both /proc and /sys parsers i'm not sure your new
setup will be any easier to handle in a program than /proc/cpuinfo. Probably not.

I would suggest you supply a standard C library and command line utility
at least - but at least for the later the output would
be likely not that different from cat /proc/cpuinfo

> Having said that, I feel Nathan's suggestion of doing it in more
> architecturally-neutral way should be better than this. We will have a
> relook at this one now.

That makes sense. /proc/cpuinfo is not that bad in itself, except that
it's very architecture dependent.

-Andi

RE: [discuss] [PATCH] Export cpu topology for IA32 and x86_64 by sysfs

[Zhang, Yanmin]

>>-----Original Message-----
>>From: Andi Kleen [mailto:ak@suse.de]
>>Sent: 2005年12月14日 11:51
>>To: Zhang, Yanmin
>>Cc: linux-kernel@vger.kernel.org; discuss@x86-64.org; Pallipadi, Venkatesh
>>Subject: Re: [discuss] [PATCH] Export cpu topology for IA32 and x86_64 by sysfs
>>
>>On Wed, Dec 14, 2005 at 11:11:00AM +0800, Zhang, Yanmin wrote:
>>> The patch exports the cpu topology info through sysfs on ia32/x86_64
>>> machines. The info is similar to /proc/cpuinfo.
>>>
>>> The exported items are:
>>> /sys/devices/system/cpu/cpuX/topology/physical_package_id(representing
>>> the physical package id of  cpu X)
>>> /sys/devices/system/cpu/cpuX/topology/core_id (representing the cpu core
>>> id  to cpu X)
>>> /sys/devices/system/cpu/cpuX/topology/thread_siblings (representing the
>>> thread siblings to cpu X)
>>> /sys/devices/system/cpu/cpuX/topology/core_siblings (represeting the
>>> core siblings to cpu X)
>>
>>Hmm, I'm not sure it is that useful. Did someone decide to move
>>all information from cpuinfo into sysfs?
It's more convenient for shell scripts to get cpu topology info from sysfs.

>>
>>And if it's done I think it needs Documentation somewhere.
There is no appropriate file to write down the info under Documentation.

>>
>>Anyways, the notifier is wrong. You need to handle CPU_UP_CANCELLED
>>too.
No. The node and related data are created/registered only when cpu is CPU_ONLINE. If CPU_UP_CANCELED is delivered to the notifier, the cpu is not online, and its node is not registered, so we needn't do anything when CPU_UP_CANCELED.

>>
>>And you could probably shrink the code size of the show function
>>in half by switching data instead of functions.
I don't quite understand what you said. My patch just uses the attribute address (a kind of data, not function) as parameter. If the function needs to be shrunken, I think I have to define a sub function per attribute which causes even longer code size.

Re: [discuss] [PATCH] Export cpu topology for IA32 and x86_64 by sysfs

[Andi Kleen]

On Wed, Dec 14, 2005 at 11:11:00AM +0800, Zhang, Yanmin wrote:
> The patch exports the cpu topology info through sysfs on ia32/x86_64
> machines. The info is similar to /proc/cpuinfo.
> 
> The exported items are:
> /sys/devices/system/cpu/cpuX/topology/physical_package_id(representing
> the physical package id of  cpu X)
> /sys/devices/system/cpu/cpuX/topology/core_id (representing the cpu core
> id  to cpu X)
> /sys/devices/system/cpu/cpuX/topology/thread_siblings (representing the
> thread siblings to cpu X)
> /sys/devices/system/cpu/cpuX/topology/core_siblings (represeting the
> core siblings to cpu X)

Hmm, I'm not sure it is that useful. Did someone decide to move
all information from cpuinfo into sysfs? 

And if it's done I think it needs Documentation somewhere.

Anyways, the notifier is wrong. You need to handle CPU_UP_CANCELLED
too.

And you could probably shrink the code size of the show function
in half by switching data instead of functions.


-Andi