linux-kernel - Re: [PATCH -v3] use per cpu data for single cpu ipi calls

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:	Fri, 30 Jan 2009 08:04:01 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Peter Zijlstra <peterz@...radead.org>
cc:	Jens Axboe <jens.axboe@...cle.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Rusty Russell <rusty@...tcorp.com.au>, npiggin@...e.de,
	Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Arjan van de Ven <arjan@...radead.org>
Subject: Re: [PATCH -v3] use per cpu data for single cpu ipi calls

On Fri, 30 Jan 2009, Peter Zijlstra wrote:
> 
> Signed-off-by: Steven Rostedt <srostedt@...hat.com>
> Signed-off-by: Peter Zijlstra <a.p.zijlstra@...llo.nl>

Acked-by: Linus Torvalds <torvalds@...ux-foundation.org>

My only question is whetherr we might even drop the kmalloc() some day: 
I suspect that the CSD_FLAG_LOCK is essentially never a contention point, 
and the cost (and occasional synchronization) of kmalloc() quite possibly 
overwhelms any theoretical scaling ability.

If another CPU hasn't even received its IPI before the same CPU sends the 
next one, I'm not sure we _want_ to send one, in fact.

But that's a secondary issue, and isn't a correctness thing, just a "do we 
really need three different allocations?" musing..

		Linus
--
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/