Re: [PATCH 00/11] x86: cpumask: some more cpumask cleanups

[Ingo Molnar]

* Mike Travis <travis@xxxxxxx> wrote:

> Here's some more cpumask cleanups.
> 
>     ia64: cpumask fix for is_affinity_mask_valid()
>     cpumask: update local_cpus_show to use new cpumask API
>     cpumask: update pci_bus_show_cpuaffinity to use new cpumask API
>     x86: cleanup remaining cpumask_t ops in smpboot code
>     x86: clean up speedstep-centrino and reduce cpumask_t usage
>     cpumask: Replace CPUMASK_ALLOC etc with cpumask_var_t.
>     cpumask: convert struct cpufreq_policy to cpumask_var_t.
>     cpumask: use work_on_cpu in acpi/cstate.c
>     cpumask: use cpumask_var_t in acpi-cpufreq.c
>     cpumask: use work_on_cpu in acpi-cpufreq.c for drv_read and drv_write
>     cpumask: use work_on_cpu in acpi-cpufreq.c for read_measured_perf_ctrs
> 
> This version basically splits out the changes to make it more 
> bisectable, and has been patch-wise compile/boot tested.  Updated stats 
> are below.

ok, i've picked them up into tip/cpus4096:

1d1a70e: cpumask: use work_on_cpu in acpi-cpufreq.c for read_measured_perf_ctrs
4d30e6b: cpumask: use work_on_cpu in acpi-cpufreq.c for drv_read and drv_write
0771cd4: cpumask: use cpumask_var_t in acpi-cpufreq.c
9fa9864: cpumask: use work_on_cpu in acpi/cstate.c
a2a8809: cpumask: convert struct cpufreq_policy to cpumask_var_t
ee557bd: cpumask: replace CPUMASK_ALLOC etc with cpumask_var_t
3744123: x86: clean up speedstep-centrino and reduce cpumask_t usage
c2d1cec: x86: cleanup remaining cpumask_t ops in smpboot code
588235b: cpumask: update pci_bus_show_cpuaffinity to use new cpumask API
3be8305: cpumask: update local_cpus_show to use new cpumask API
d3b66bf: ia64: cpumask fix for is_affinity_mask_valid()

( Sidenote, your mail scripts have a bug that do this to the Subject line:

    Subject: [PATCH 05/11] x86: clean up speedstep-centrino and reduce 
    cpumask_t usage From: Rusty Russell <rusty@xxxxxxxxxxxxxxx>

  i've fixed them up manually so that Rusty is in the Author field. )


> The number of stack hogs have been significantly reduced:
> 
> ====== Stack (-l 500)
>     1 - allyesconfig-128
>     2 - allyesconfig-4k
> 
>   .1.    .2.    ..final..
>     0  +1032   1032      .  flush_tlb_page
>     0  +1024   1024      .  kvm_reload_remote_mmus
>     0  +1024   1024      .  kvm_flush_remote_tlbs
>     0  +1024   1024      .  flush_tlb_mm
>     0  +1024   1024      .  flush_tlb_current_task

Quite good! Can we fix those TLB flush cpumask uses too?

> And the overall memory usage is becoming quite less affected by changing
> NR_CPUS from 128 to 4096:
[...]
>         .1.       .2.    ..final..
>    11436936  +4167424    15604360   +36%  .bss

.bss seems to account for ~80% of the increase. Are these static cpumasks, 
or do we still have NR_CPUS arrays around?

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/