1. 05 5月, 2009 1 次提交
    • A
      x86: show number of core_siblings instead of thread_siblings in /proc/cpuinfo · 35d11680
      Andreas Herrmann 提交于
      Commit 7ad728f9
      (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: NAndreas Herrmann <andreas.herrmann3@amd.com>
      Cc: Rusty Russell <rusty@rustcorp.com.au>
      LKML-Reference: <20090504182859.GA29045@alberich.amd.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      35d11680
  2. 04 5月, 2009 1 次提交
  3. 02 5月, 2009 1 次提交
  4. 30 4月, 2009 14 次提交
  5. 29 4月, 2009 23 次提交