public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* RE: [PATCH v2:3/3]Export cpu topology by sysfs
@ 2005-12-31  8:43 Zhang, Yanmin
  2006-01-04  9:06 ` [PATCH v3]Export " Yanmin Zhang
  2006-01-09  4:51 ` [PATCH v2:3/3]Export " Nathan Lynch
  0 siblings, 2 replies; 8+ messages in thread
From: Zhang, Yanmin @ 2005-12-31  8:43 UTC (permalink / raw)
  To: Nathan Lynch
  Cc: Yanmin Zhang, greg, linux-kernel, discuss, linux-ia64,
	Siddha, Suresh B, Shah, Rajesh, Pallipadi, Venkatesh

>>-----Original Message-----
>>From: linux-ia64-owner@vger.kernel.org [mailto:linux-ia64-owner@vger.kernel.org] On Behalf Of Nathan Lynch
>>Sent: 2005年12月29日 3:14
>>To: Zhang, Yanmin
>>Cc: Yanmin Zhang; greg@kroah.com; linux-kernel@vger.kernel.org; discuss@x86-64.org; linux-ia64@vger.kernel.org; Siddha, Suresh B; Shah,
>>Rajesh; Pallipadi, Venkatesh
>>Subject: Re: [PATCH v2:3/3]Export cpu topology by sysfs
>>
>>
>>> >>What about sane default values for the *_id attributes?
>>Not really -- inevitably we'll wind up with an interface that has
>>slightly different semantics on each architecture.
How about below arrangement for default values?
1) physical_package_id: If cpu has no physical package id, the logical cpu id will be picked up.
2) core_id: 0. If cpu doesn't support multi-core, its core id is 0. 
3) thread_siblings: Just include itself, if the cpu doesn't support HT/multi-thread.
4) core_siblings: Just include itself, if the cpu doesn't support multi-core and HT.


>>
>>> >>Hmm, why should thread_id be exported at all?  Is it useful to
>>> >>userspace in a way that the logical cpu id is not?
>>>
>>> Just to make it clearer. Of course, physical_package_id /core_id/
>>> logical cpu id could tell enough info like thread id.
>>
>>Then let's drop thread_id until there's a need for it.
Ok. 


>>> >>> +	switch (action) {
>>> >>> +		case CPU_ONLINE:
>>> >>> +			topology_add_dev(sys_dev);
>>> >>> +			break;
>>> >>> +		case CPU_DEAD:
>>> >>> +			topology_remove_dev(sys_dev);
>>> >>> +			break;
>>> >>> +	}
>>> >>> +	return NOTIFY_OK;
>>> >>> +}
>>> >>
>>> >>I don't think it makes much sense to add and remove the attribute
>>> >>group for cpu online/offline events.  The topology information for an
>>> >>offline cpu is potentially valuable -- it could help the admin decide
>>> >>which processor to online at runtime, for example.
>>> >>
>>> >>I believe the correct time to update the topology information is when
>>> >>the topology actually changes (e.g. physical addition or removal of a
>>> >>processor) -- this is independent of online/offline operations.
>>>
>>> Currently, on i386/x86_64/ia64, a cpu gets its own topology by
>>> itself and fills into a global array. If the cpu is offline since
>>> the machine is booted, we can't get its topology info.
>>
>>Hmm, is this a limitation of those architectures?  On ppc64 (where
>>this feature would be applicable) Open Firmware provides such topology
>>information regardless of the cpus' states; does the firmware or ACPI
>>on these platforms not do the same?
On I386/x86_64/IA64, MADT, an ACPI table, provides apic id for all cpus. But we can't divide it to get core id and thread id becasue we couldn't know how many bits of apic id are for core id and how many bits are for thread id. These info are got only by executing cupid (on i386/x86_64) or PAL call (on ia64) by the online cpu itself.

>>
>>> And when a cpu is offline, current kernel deletes it from the
>>> thread_siblings and core_siblings of other cpu.
>>
>>That's fine -- I'm just arguing against the addition/removal of the
>>attributes when cpus go online and offline.
Based on above discussion, if the attributes of the cpu is not removed when the cpu is offline, the attribute values might be incorrect when the cpu is not up since machine boots.


^ permalink raw reply	[flat|nested] 8+ messages in thread
* RE: [PATCH v3]Export cpu topology by sysfs
@ 2006-01-09  6:47 Zhang, Yanmin
  0 siblings, 0 replies; 8+ messages in thread
From: Zhang, Yanmin @ 2006-01-09  6:47 UTC (permalink / raw)
  To: Nathan Lynch, Yanmin Zhang
  Cc: linux-kernel, greg, discuss, linux-ia64, Siddha, Suresh B,
	Shah, Rajesh, Pallipadi, Venkatesh

>>-----Original Message-----
>>From: linux-ia64-owner@vger.kernel.org [mailto:linux-ia64-owner@vger.kernel.org] On Behalf Of Nathan Lynch
>>Sent: 2006年1月9日 13:10
>>To: Yanmin Zhang
>>Cc: linux-kernel@vger.kernel.org; greg@kroah.com; discuss@x86-64.org; linux-ia64@vger.kernel.org; Siddha, Suresh B; Shah, Rajesh;
>>Pallipadi, Venkatesh
>>Subject: Re: [PATCH v3]Export cpu topology by sysfs
>>> 2) Set consistent default values for the 4 attributes.
>>>
>>
>><snip>
>>
>>> If one architecture wants to support this feature, it just needs to
>>> implement 4 defines, typically in file include/asm-XXX/topology.h.
>>> The 4 defines are:
>>> #define topology_physical_package_id(cpu)
>>> #define topology_core_id(cpu)
>>> #define topology_thread_siblings(cpu)
>>> #define topology_core_siblings(cpu)
>>>
>>> The type of **_id is int.
>>> The type of siblings is cpumask_t.
>>>
>>> To be consistent on all architectures, the 4 attributes should have
>>> deafult values if their values are unavailable. Below is the rule.
>>> 1) physical_package_id: If cpu has no physical package id, -1 is the
>>> default value.
>>> 2) core_id: If cpu doesn't support multi-core, its core id is 0.
>>
>>Why not -1 as with the physical package id?  0 could be a valid core
>>id.
If the cpu has only 1 core, we could call it single-core, so it's reasonable to use 0 as its core id.


>>
>>> 3) thread_siblings: Just include itself, if the cpu doesn't support
>>> HT/multi-thread.
>>> 4) core_siblings: Just include itself, if the cpu doesn't support
>>> multi-core and HT/Multi-thread.
>>
>>Really, I think the least confusing interface would not export those
>>attributes which are not relevant for the system.  E.g. if the system
>>isn't multi-core, you don't see core_id and core_siblings attributes.
>>
>>Failing that, let's at least have consistent, unambiguous values for
>>the ids which are not applicable.
Current kernel will output core id by /proc/cpuinfo if a physical cpu has 2 threads, no matter if it's a multi-core, or just a multi-thread. To be consistent with /proc/cpuinfo, I think we need export core id and its default value is 0.

>>
>><snip>
>>> +static int __cpuinit topology_cpu_callback(struct notifier_block *nfb,
>>> +		unsigned long action, void *hcpu)
>>> +{
>>> +	unsigned int cpu = (unsigned long)hcpu;
>>> +	struct sys_device *sys_dev;
>>> +
>>> +	sys_dev = get_cpu_sysdev(cpu);
>>> +	switch (action) {
>>> +		case CPU_ONLINE:
>>> +			topology_add_dev(sys_dev);
>>> +			break;
>>> +		case CPU_DEAD:
>>> +			topology_remove_dev(sys_dev);
>>> +			break;
>>> +	}
>>> +	return NOTIFY_OK;
>>> +}
>>
>>I still oppose this bit.  I want the attributes there for powerpc even
>>for offline cpus -- the topology information (if obtainable, which it
>>is on powerpc) is useful regardless of the cpu's online state.  The
>>attributes should appear when a cpu is made present, and go away when
>>a cpu is removed.
As my previous email says, there are concerns/issues to do so. A compromise is that the patch could register a sysdev driver. When the cpu becomes offline from online, we don't delete the topology kobj. The compromise has a defect. If the cpu is never online since machine boots, the topology info of the cpu is incorrect. 

>>
>>This week I'll try to do an implementation for powerpc.

^ permalink raw reply	[flat|nested] 8+ messages in thread
* RE: [PATCH v3]Export cpu topology by sysfs
@ 2006-01-25  2:05 Zhang, Yanmin
  2006-01-25  2:34 ` Yanmin Zhang
  2006-01-26  5:11 ` Nathan Lynch
  0 siblings, 2 replies; 8+ messages in thread
From: Zhang, Yanmin @ 2006-01-25  2:05 UTC (permalink / raw)
  To: Nathan Lynch, Andrew Morton
  Cc: linux-kernel, greg, discuss, linux-ia64, Siddha, Suresh B,
	Shah, Rajesh, Pallipadi, Venkatesh, Yanmin Zhang

>>-----Original Message-----
>>From: linux-ia64-owner@vger.kernel.org [mailto:linux-ia64-owner@vger.kernel.org] On Behalf Of Zhang, Yanmin
>>Sent: 2006年1月9日 14:48
>>To: Nathan Lynch; Yanmin Zhang
>>Cc: linux-kernel@vger.kernel.org; greg@kroah.com; discuss@x86-64.org; linux-ia64@vger.kernel.org; Siddha, Suresh B; Shah, Rajesh;
>>Pallipadi, Venkatesh
>>Subject: RE: [PATCH v3]Export cpu topology by sysfs
>>
>>>>-----Original Message-----
>>>>From: linux-ia64-owner@vger.kernel.org [mailto:linux-ia64-owner@vger.kernel.org] On Behalf Of Nathan Lynch
>>>>Sent: 2006年1月9日 13:10
>>>>To: Yanmin Zhang
>>>>Cc: linux-kernel@vger.kernel.org; greg@kroah.com; discuss@x86-64.org; linux-ia64@vger.kernel.org; Siddha, Suresh B; Shah, Rajesh;
>>>>Pallipadi, Venkatesh
>>>>Subject: Re: [PATCH v3]Export cpu topology by sysfs
>>>>> 2) Set consistent default values for the 4 attributes.
>>>>>
>>>>
>>>><snip>
>>>>
>>>>> If one architecture wants to support this feature, it just needs to
>>>>> implement 4 defines, typically in file include/asm-XXX/topology.h.
>>>>> The 4 defines are:
>>>>> #define topology_physical_package_id(cpu)
>>>>> #define topology_core_id(cpu)
>>>>> #define topology_thread_siblings(cpu)
>>>>> #define topology_core_siblings(cpu)
>>>>>
>>>>> The type of **_id is int.
>>>>> The type of siblings is cpumask_t.
>>>>>
>>>>> To be consistent on all architectures, the 4 attributes should have
>>>>> deafult values if their values are unavailable. Below is the rule.
>>>>> 1) physical_package_id: If cpu has no physical package id, -1 is the
>>>>> default value.
>>>>> 2) core_id: If cpu doesn't support multi-core, its core id is 0.
>>>>
>>>>Why not -1 as with the physical package id?  0 could be a valid core
>>>>id.
>>If the cpu has only 1 core, we could call it single-core, so it's reasonable to use 0 as its core id.
>>
>>
>>>>
>>>>> 3) thread_siblings: Just include itself, if the cpu doesn't support
>>>>> HT/multi-thread.
>>>>> 4) core_siblings: Just include itself, if the cpu doesn't support
>>>>> multi-core and HT/Multi-thread.
>>>>
>>>>Really, I think the least confusing interface would not export those
>>>>attributes which are not relevant for the system.  E.g. if the system
>>>>isn't multi-core, you don't see core_id and core_siblings attributes.
>>>>
>>>>Failing that, let's at least have consistent, unambiguous values for
>>>>the ids which are not applicable.
>>Current kernel will output core id by /proc/cpuinfo if a physical cpu has 2 threads, no matter if it's a multi-core, or just a multi-thread.
>>To be consistent with /proc/cpuinfo, I think we need export core id and its default value is 0.
>>
>>>>
>>>><snip>
>>>>> +static int __cpuinit topology_cpu_callback(struct notifier_block *nfb,
>>>>> +		unsigned long action, void *hcpu)
>>>>> +{
>>>>> +	unsigned int cpu = (unsigned long)hcpu;
>>>>> +	struct sys_device *sys_dev;
>>>>> +
>>>>> +	sys_dev = get_cpu_sysdev(cpu);
>>>>> +	switch (action) {
>>>>> +		case CPU_ONLINE:
>>>>> +			topology_add_dev(sys_dev);
>>>>> +			break;
>>>>> +		case CPU_DEAD:
>>>>> +			topology_remove_dev(sys_dev);
>>>>> +			break;
>>>>> +	}
>>>>> +	return NOTIFY_OK;
>>>>> +}
>>>>
>>>>I still oppose this bit.  I want the attributes there for powerpc even
>>>>for offline cpus -- the topology information (if obtainable, which it
>>>>is on powerpc) is useful regardless of the cpu's online state.  The
>>>>attributes should appear when a cpu is made present, and go away when
>>>>a cpu is removed.
>>As my previous email says, there are concerns/issues to do so. A compromise is that the patch could register a sysdev driver. When the
>>cpu becomes offline from online, we don't delete the topology kobj. The compromise has a defect. If the cpu is never online since machine
>>boots, the topology info of the cpu is incorrect.
>>
>>>>
>>>>This week I'll try to do an implementation for powerpc.
Nathan,

Is your implementation for powerpc ready?

Andrew,
Could the patch of version 3 be put into mm tree firstly?

Thanks,
Yanmin


^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2006-01-26  5:11 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-12-31  8:43 [PATCH v2:3/3]Export cpu topology by sysfs Zhang, Yanmin
2006-01-04  9:06 ` [PATCH v3]Export " Yanmin Zhang
2006-01-09  5:10   ` Nathan Lynch
2006-01-09  4:51 ` [PATCH v2:3/3]Export " Nathan Lynch
  -- strict thread matches above, loose matches on Subject: below --
2006-01-09  6:47 [PATCH v3]Export " Zhang, Yanmin
2006-01-25  2:05 Zhang, Yanmin
2006-01-25  2:34 ` Yanmin Zhang
2006-01-26  5:11 ` Nathan Lynch

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox