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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Sun, 4 Jan 2009 15:44:54 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	Mike Travis <travis@....com>
Cc:	Ingo Molnar <mingo@...hat.com>,
	Rusty Russell <rusty@...tcorp.com.au>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jack Steiner <steiner@....com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/11] x86: cpumask: some more cpumask cleanups


* Mike Travis <travis@....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:

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

  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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/