linux-kernel - Re: [RFC 00/13] smp: reduce stack requirements for genapic send_IPI

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 for Android: free password hash cracker in your pocket

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

Message-ID: <48C541EF.3040404@sgi.com>
Date:	Mon, 08 Sep 2008 08:17:03 -0700
From:	Mike Travis <travis@....com>
To:	Ingo Molnar <mingo@...e.hu>
CC:	Andrew Morton <akpm@...ux-foundation.org>, davej@...emonkey.org.uk,
	David Miller <davem@...emloft.net>,
	Eric Dumazet <dada1@...mosbay.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	Jack Steiner <steiner@....com>,
	Jeremy Fitzhardinge <jeremy@...p.org>,
	Jes Sorensen <jes@....com>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [RFC 00/13] smp: reduce stack requirements for genapic	send_IPI_mask
 functions

Ingo Molnar wrote:
> * Mike Travis <travis@....com> wrote:
> 
>> [Note: all these changes require some more testing but I wanted to 
>> solicit comments before then, hence the "RFC" in the subject line. 
>> -thanks! Mike]
> 
> these changes are certainly looking very nice.
> 
> They do interact with a ton of high-flux topics in -tip, so i'd prefer 
> to start integrating/testing this straight away (today-ish), before the 
> target moves yet again. Are there any showstoppers that speak against 
> that?
> 
> The plan would be to not keep this in a single topic but to spread them 
> into their closest topic (tip/x86/x2apic, tip/irq/sparseirq etc.) - are 
> there any cross-topic dependencies to be careful about? Most of the 
> commits seem to be standalone. The debug patch would go into 
> tip/cpus4096.
> 
> And more generally: how far away are we from being able to introduce 
> struct cpumask and hide its implementation from most .c files? That 
> would be rather efficient in preventing it from being put on the stack 
> spuriously in one of the 30+ thousand Linux kernel source code files. 
> Just like we hide the true structure of things like 'struct kmem_cache' 
> and force them to always be used as pointers.
> 
> 	Ingo

What I'll do is resubmit the changes that have nothing to do with
cpumask_ptr's first as they are mostly just "cleaning up extraneous
temp cpumask variables".  Then I'll try the redefine of cpumask_t to
see what kind of hornet's nest is opened up.

What do you think of a pool of temp cpumask_t's?  That way, they
could be made available early (before kmalloc is available).  An
atomic op could be used for reservation which when the zero-based
percpu variables finally get completed, become very low cost.

Thanks,
Mike
--
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/