From: Nathan Lynch <ntl@pobox.com>
To: Yanmin Zhang <ymzhang@unix-os.sc.intel.com>
Cc: linux-kernel@vger.kernel.org, greg@kroah.com, discuss@x86-64.org,
linux-ia64@vger.kernel.org, "Siddha,
Suresh B" <suresh.b.siddha@intel.com>,
"Shah, Rajesh" <rajesh.shah@intel.com>,
"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Subject: Re: [PATCH v3]Export cpu topology by sysfs
Date: Mon, 09 Jan 2006 05:10:07 +0000 [thread overview]
Message-ID: <20060109051006.GC2683@localhost.localdomain> (raw)
In-Reply-To: <20060104010658.A16342@unix-os.sc.intel.com>
(sorry for the delay in response)
Yanmin Zhang wrote:
> Here is version 3. Based on Nathan's comments, the main changes are:
> 1) Drop thread id, so the first 2 patches of version 2 are dropped;
Thanks.
> 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.
> 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.
<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.
This week I'll try to do an implementation for powerpc.
WARNING: multiple messages have this Message-ID (diff)
From: Nathan Lynch <ntl@pobox.com>
To: Yanmin Zhang <ymzhang@unix-os.sc.intel.com>
Cc: linux-kernel@vger.kernel.org, greg@kroah.com, discuss@x86-64.org,
linux-ia64@vger.kernel.org, "Siddha,
Suresh B" <suresh.b.siddha@intel.com>,
"Shah, Rajesh" <rajesh.shah@intel.com>,
"Pallipadi, Venkatesh" <venkatesh.pallipadi@intel.com>
Subject: Re: [PATCH v3]Export cpu topology by sysfs
Date: Sun, 8 Jan 2006 23:10:07 -0600 [thread overview]
Message-ID: <20060109051006.GC2683@localhost.localdomain> (raw)
In-Reply-To: <20060104010658.A16342@unix-os.sc.intel.com>
(sorry for the delay in response)
Yanmin Zhang wrote:
> Here is version 3. Based on Nathan's comments, the main changes are:
> 1) Drop thread id, so the first 2 patches of version 2 are dropped;
Thanks.
> 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.
> 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.
<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.
This week I'll try to do an implementation for powerpc.
next prev parent reply other threads:[~2006-01-09 5:10 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-21 2:09 [PATCH v2:3/3]Export cpu topology by sysfs Yanmin Zhang
2005-12-21 2:09 ` Yanmin Zhang
2005-12-23 0:16 ` Greg KH
2005-12-23 0:16 ` Greg KH
2005-12-23 4:03 ` Zhang, Yanmin
2005-12-23 4:03 ` Zhang, Yanmin
2005-12-23 19:16 ` Greg KH
2005-12-23 19:16 ` Greg KH
2005-12-26 7:38 ` Zhang, Yanmin
2005-12-26 7:38 ` Zhang, Yanmin
2005-12-26 8:28 ` Yanmin Zhang
2005-12-26 8:28 ` Yanmin Zhang
2005-12-27 5:36 ` Greg KH
2005-12-27 5:36 ` Greg KH
2005-12-27 5:35 ` Greg KH
2005-12-27 5:35 ` Greg KH
2005-12-27 10:22 ` Zhang, Yanmin
2005-12-27 10:22 ` Zhang, Yanmin
2005-12-27 10:41 ` Yanmin Zhang
2005-12-27 10:41 ` Yanmin Zhang
2005-12-27 21:19 ` Nathan Lynch
2005-12-27 21:19 ` Nathan Lynch
2005-12-28 13:46 ` Zhang, Yanmin
2005-12-28 13:46 ` Zhang, Yanmin
2005-12-28 19:14 ` Nathan Lynch
2005-12-28 19:14 ` Nathan Lynch
2005-12-31 8:43 ` Zhang, Yanmin
2005-12-31 8:43 ` Zhang, Yanmin
2006-01-04 9:06 ` [PATCH v3]Export " Yanmin Zhang
2006-01-04 9:06 ` Yanmin Zhang
2006-01-09 5:10 ` Nathan Lynch [this message]
2006-01-09 5:10 ` Nathan Lynch
2006-01-09 6:47 ` Zhang, Yanmin
2006-01-09 6:47 ` Zhang, Yanmin
2006-01-25 2:05 ` Zhang, Yanmin
2006-01-25 2:05 ` Zhang, Yanmin
2006-01-25 2:34 ` Yanmin Zhang
2006-01-25 2:34 ` Yanmin Zhang
2006-01-26 5:11 ` Nathan Lynch
2006-01-26 5:11 ` Nathan Lynch
2006-01-09 4:51 ` [PATCH v2:3/3]Export " Nathan Lynch
2006-01-09 4:51 ` Nathan Lynch
2006-01-09 6:35 ` Zhang, Yanmin
2006-01-09 6:35 ` Zhang, Yanmin
2006-01-09 17:41 ` Russ Anderson
2006-01-09 17:41 ` Russ Anderson
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=20060109051006.GC2683@localhost.localdomain \
--to=ntl@pobox.com \
--cc=discuss@x86-64.org \
--cc=greg@kroah.com \
--cc=linux-ia64@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rajesh.shah@intel.com \
--cc=suresh.b.siddha@intel.com \
--cc=venkatesh.pallipadi@intel.com \
--cc=ymzhang@unix-os.sc.intel.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.