* x86: changed output in /proc/cpuinfo for siblings
@ 2009-05-04 18:28 Andreas Herrmann
2009-05-04 18:32 ` Ingo Molnar
2009-05-04 18:39 ` [tip:x86/urgent] x86: show number of core_siblings instead of thread_siblings in /proc/cpuinfo tip-bot for Andreas Herrmann
0 siblings, 2 replies; 3+ messages in thread
From: Andreas Herrmann @ 2009-05-04 18:28 UTC (permalink / raw)
To: Ingo Molnar, Rusty Russell; +Cc: linux-kernel, Thomas Gleixner, H. Peter Anvin
Commit 7ad728f98162cb1af06a85b2a5fc422dddd4fb78
(cpumask: x86: convert cpu_sibling_map/cpu_core_map to cpumask_var_t)
changed the output of /proc/cpuinfo for siblings:
Example on an AMD Phenom:
physical id : 0
siblings : 1
core id : 3
cpu cores : 4
Before that commit it was:
physical id : 0
siblings : 4
core id : 3
cpu cores : 4
Instead of cpu_core_mask it now uses cpu_sibling_mask to count siblings.
This is due to the following hunk of above commit:
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -14,7 +14,7 @@ static void show_cpuinfo_core(struct seq_file *m, struct cpuinf
if (c->x86_max_cores * smp_num_siblings > 1) {
seq_printf(m, "physical id\t: %d\n", c->phys_proc_id);
seq_printf(m, "siblings\t: %d\n",
- cpus_weight(per_cpu(cpu_core_map, cpu)));
+ cpumask_weight(cpu_sibling_mask(cpu)));
seq_printf(m, "core id\t\t: %d\n", c->cpu_core_id);
seq_printf(m, "cpu cores\t: %d\n", c->booted_cores);
seq_printf(m, "apicid\t\t: %d\n", c->apicid);
Was this the intention or just a mistake?
In the latter case attached patch reverts this hunk.
Regards,
Andreas
---
x86: show number of core_siblings instead of thread_siblings in /proc/cpuinfo
Commit 7ad728f98162cb1af06a85b2a5fc422dddd4fb78 (cpumask: x86: convert
cpu_sibling_map/cpu_core_map to cpumask_var_t) changed the value for
siblings in /proc/cpuinfo to be the number of thread_siblings instead
of core_siblings.
Revert the respective hunk to restore the old behavior.
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
---
diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index f93047f..d5e3039 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -14,7 +14,7 @@ static void show_cpuinfo_core(struct seq_file *m, struct cpuinfo_x86 *c,
if (c->x86_max_cores * smp_num_siblings > 1) {
seq_printf(m, "physical id\t: %d\n", c->phys_proc_id);
seq_printf(m, "siblings\t: %d\n",
- cpumask_weight(cpu_sibling_mask(cpu)));
+ cpumask_weight(cpu_core_mask(cpu)));
seq_printf(m, "core id\t\t: %d\n", c->cpu_core_id);
seq_printf(m, "cpu cores\t: %d\n", c->booted_cores);
seq_printf(m, "apicid\t\t: %d\n", c->apicid);
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: x86: changed output in /proc/cpuinfo for siblings
2009-05-04 18:28 x86: changed output in /proc/cpuinfo for siblings Andreas Herrmann
@ 2009-05-04 18:32 ` Ingo Molnar
2009-05-04 18:39 ` [tip:x86/urgent] x86: show number of core_siblings instead of thread_siblings in /proc/cpuinfo tip-bot for Andreas Herrmann
1 sibling, 0 replies; 3+ messages in thread
From: Ingo Molnar @ 2009-05-04 18:32 UTC (permalink / raw)
To: Andreas Herrmann
Cc: Rusty Russell, linux-kernel, Thomas Gleixner, H. Peter Anvin
* Andreas Herrmann <andreas.herrmann3@amd.com> wrote:
> Commit 7ad728f98162cb1af06a85b2a5fc422dddd4fb78
> (cpumask: x86: convert cpu_sibling_map/cpu_core_map to cpumask_var_t)
> changed the output of /proc/cpuinfo for siblings:
>
> Example on an AMD Phenom:
>
> physical id : 0
> siblings : 1
> core id : 3
> cpu cores : 4
>
> Before that commit it was:
>
> physical id : 0
> siblings : 4
> core id : 3
> cpu cores : 4
>
> Instead of cpu_core_mask it now uses cpu_sibling_mask to count siblings.
> This is due to the following hunk of above commit:
>
> --- a/arch/x86/kernel/cpu/proc.c
> +++ b/arch/x86/kernel/cpu/proc.c
> @@ -14,7 +14,7 @@ static void show_cpuinfo_core(struct seq_file *m, struct cpuinf
> if (c->x86_max_cores * smp_num_siblings > 1) {
> seq_printf(m, "physical id\t: %d\n", c->phys_proc_id);
> seq_printf(m, "siblings\t: %d\n",
> - cpus_weight(per_cpu(cpu_core_map, cpu)));
> + cpumask_weight(cpu_sibling_mask(cpu)));
> seq_printf(m, "core id\t\t: %d\n", c->cpu_core_id);
> seq_printf(m, "cpu cores\t: %d\n", c->booted_cores);
> seq_printf(m, "apicid\t\t: %d\n", c->apicid);
>
> Was this the intention or just a mistake?
it was a mistake, because the impact-line does not mention this
side-effect:
Impact: reduce per-cpu size for CONFIG_CPUMASK_OFFSTACK=y
> In the latter case attached patch reverts this hunk.
applied, thanks!
Ingo
^ permalink raw reply [flat|nested] 3+ messages in thread
* [tip:x86/urgent] x86: show number of core_siblings instead of thread_siblings in /proc/cpuinfo
2009-05-04 18:28 x86: changed output in /proc/cpuinfo for siblings Andreas Herrmann
2009-05-04 18:32 ` Ingo Molnar
@ 2009-05-04 18:39 ` tip-bot for Andreas Herrmann
1 sibling, 0 replies; 3+ messages in thread
From: tip-bot for Andreas Herrmann @ 2009-05-04 18:39 UTC (permalink / raw)
To: linux-tip-commits
Cc: linux-kernel, hpa, mingo, rusty, andreas.herrmann3, tglx, mingo
Commit-ID: 35d11680a9d82c93eb92f08f9702b72877427b4a
Gitweb: http://git.kernel.org/tip/35d11680a9d82c93eb92f08f9702b72877427b4a
Author: Andreas Herrmann <andreas.herrmann3@amd.com>
AuthorDate: Mon, 4 May 2009 20:28:59 +0200
Committer: Ingo Molnar <mingo@elte.hu>
CommitDate: Mon, 4 May 2009 20:36:49 +0200
x86: show number of core_siblings instead of thread_siblings in /proc/cpuinfo
Commit 7ad728f98162cb1af06a85b2a5fc422dddd4fb78
(cpumask: x86: convert cpu_sibling_map/cpu_core_map to cpumask_var_t)
changed the output of /proc/cpuinfo for siblings:
Example on an AMD Phenom:
physical id : 0
siblings : 1
core id : 3
cpu cores : 4
Before that commit it was:
physical id : 0
siblings : 4
core id : 3
cpu cores : 4
Instead of cpu_core_mask it now uses cpu_sibling_mask to count siblings.
This is due to the following hunk of above commit:
| --- a/arch/x86/kernel/cpu/proc.c
| +++ b/arch/x86/kernel/cpu/proc.c
| @@ -14,7 +14,7 @@ static void show_cpuinfo_core(struct seq_file *m, struct cpuinf
| if (c->x86_max_cores * smp_num_siblings > 1) {
| seq_printf(m, "physical id\t: %d\n", c->phys_proc_id);
| seq_printf(m, "siblings\t: %d\n",
| - cpus_weight(per_cpu(cpu_core_map, cpu)));
| + cpumask_weight(cpu_sibling_mask(cpu)));
| seq_printf(m, "core id\t\t: %d\n", c->cpu_core_id);
| seq_printf(m, "cpu cores\t: %d\n", c->booted_cores);
| seq_printf(m, "apicid\t\t: %d\n", c->apicid);
This was a mistake, because the impact line shows that this side-effect
was not anticipated:
Impact: reduce per-cpu size for CONFIG_CPUMASK_OFFSTACK=y
So revert the respective hunk to restore the old behavior.
[ Impact: fix sibling-info regression in /proc/cpuinfo ]
Signed-off-by: Andreas Herrmann <andreas.herrmann3@amd.com>
Cc: Rusty Russell <rusty@rustcorp.com.au>
LKML-Reference: <20090504182859.GA29045@alberich.amd.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/kernel/cpu/proc.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/cpu/proc.c b/arch/x86/kernel/cpu/proc.c
index f93047f..d5e3039 100644
--- a/arch/x86/kernel/cpu/proc.c
+++ b/arch/x86/kernel/cpu/proc.c
@@ -14,7 +14,7 @@ static void show_cpuinfo_core(struct seq_file *m, struct cpuinfo_x86 *c,
if (c->x86_max_cores * smp_num_siblings > 1) {
seq_printf(m, "physical id\t: %d\n", c->phys_proc_id);
seq_printf(m, "siblings\t: %d\n",
- cpumask_weight(cpu_sibling_mask(cpu)));
+ cpumask_weight(cpu_core_mask(cpu)));
seq_printf(m, "core id\t\t: %d\n", c->cpu_core_id);
seq_printf(m, "cpu cores\t: %d\n", c->booted_cores);
seq_printf(m, "apicid\t\t: %d\n", c->apicid);
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2009-05-04 18:40 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-04 18:28 x86: changed output in /proc/cpuinfo for siblings Andreas Herrmann
2009-05-04 18:32 ` Ingo Molnar
2009-05-04 18:39 ` [tip:x86/urgent] x86: show number of core_siblings instead of thread_siblings in /proc/cpuinfo tip-bot for Andreas Herrmann
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome