linux-kernel - Re: [git pull] cpus4096 tree, part 3

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]

Message-Id: <200901041405.15096.rusty@rustcorp.com.au>
Date:	Sun, 4 Jan 2009 14:05:14 +1030
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Ingo Molnar <mingo@...e.hu>, Mike Travis <travis@....com>,
	linux-kernel@...r.kernel.org
Subject: Re: [git pull] cpus4096 tree, part 3

On Sunday 04 January 2009 07:26:03 Linus Torvalds wrote:
> 
> On Sat, 3 Jan 2009, Ingo Molnar wrote:
> > 
> > > Has anybody looked at what the stack size is with MAXSMP set with an 
> > > allyesconfig? And what areas are still problematic, if any? Are we going 
> > > to have some code-paths that still essentially have 1kB+ of stack space 
> > > just because they haven't been converted and still have the cpu mask on 
> > > stack?
> > 
> > ok, indeed testing of that is in order now.
> 
> Well, since I can compile a allyesconfig pretty quickly, I did the static 
> part. It looks better than it used to, and I think most of the huge stacks 
> are totally unrealted to cpu masks. But not all.
> 
> But it looks like we have a few:
> 
>  - flush_tlb_current_task:
> 	cpumask_t cpu_mask;
>  - flush_tlb_mm:
> 	cpumask_t cpu_mask;
...
>  - acpi_cpufreq_target:
> 	cpumask_t online_policy_cpus

Mike?  These are x86-specific...

>  - local_cpus_show:
> 	cpumask_t mask;
>  - local_cpulist_show:
> 	cpumask_t mask;

Yes, this removal is still in my queue.  I'll double-check that all the
archs have the new "cpumask_of_pcibus". (cpumask:replace-and-remove-pcibus_to_cpumask.patch "cpumask: remove the now-obsoleted pcibus_to_cpumask()").

> and then we have a number of things that have "struct cpufreq_policy" on 
> the stack, and those things have two cpumask_t's in each.

Yep, we have the conversion for that too.  Mike, it's cpumask:convert-drivers_acpi.patch "cpumask: convert struct cpufreq_policy to cpumask_var_t."

> The rest of the high-stack-usage cases - from a _very_ quick look - seem 
> to be unrelated to CPU masks, but in the "more than 1kB of stack" group 
> about a third (wild handwaving eyeballing) of them do seem to be related 
> to cpumask.

Mike was tracking this; I think he has a script to set NR_CPUS small then
large and dump the changes.

Cheers,
Rusty.
--
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/