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

[Mike Travis <travis@sgi.com>]

Ingo Molnar wrote:
> * Mike Travis <travis@sgi.com> 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:

Thanks Ingo!

> 
> 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@rustcorp.com.au>

It's in quilt mail (even the latest version), but since it's a script, I'll
see about fixing it manually.

> 
>   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?

I've looked at the tlb ones and they are hairy.  But we now have a few more
facilities in place so I'll revisit them.

> 
>> 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?

There are 72 arrays still using NR_CPUS (though some legitimately) and 14 static
cpumask_t's and 11 "DECLARE_BITMAP(..., NR_CPUS)".

There are also about 5 patches left in my queue that need further testing with
the latest tip code.

Thanks,
Mike