linux-kernel - Re: [this_cpu_xx V6 7/7] this_cpu: slub aggressive use of this

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: <84144f020910120614r529d8e4em9babe83a90e9371f@mail.gmail.com>
Date:	Mon, 12 Oct 2009 16:14:01 +0300
From:	Pekka Enberg <penberg@...helsinki.fi>
To:	Tejun Heo <tj@...nel.org>
Cc:	cl@...ux-foundation.org, linux-kernel@...r.kernel.org,
	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>,
	Mel Gorman <mel@....ul.ie>,
	David Rientjes <rientjes@...gle.com>,
	Zhang Yanmin <yanmin_zhang@...ux.intel.com>
Subject: Re: [this_cpu_xx V6 7/7] this_cpu: slub aggressive use of this_cpu 
	operations in the hotpaths

On Mon, Oct 12, 2009 at 1:40 PM, Tejun Heo <tj@...nel.org> wrote:
> cl@...ux-foundation.org wrote:
>> Use this_cpu_* operations in the hotpath to avoid calculations of
>> kmem_cache_cpu pointer addresses.
>>
>> On x86 there is a trade off: Multiple uses segment prefixes against an
>> address calculation and more register pressure. Code size is reduced
>> also therefore it is an advantage icache wise.
>>
>> The use of prefixes is necessary if we want to use a scheme
>> for fastpaths that do not require disabling interrupts.
>>
>> Cc: Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
>> Cc: Pekka Enberg <penberg@...helsinki.fi>
>> Signed-off-by: Christoph Lameter <cl@...ux-foundation.org>
>
> The rest of the patches look good to me but I'm no expert in this area
> of code.  But you're the maintainer of the allocator and the changes
> definitely are percpu related, so if you're comfortable with it, I can
> happily carry the patches through percpu tree.

The patch looks sane to me but the changelog contains no relevant
numbers on performance. I am fine with the patch going in -percpu but
the patch probably needs some more beating performance-wise before it
can go into .33. I'm CC'ing some more people who are known to do SLAB
performance testing just in case they're interested in looking at the
patch. In any case,

Acked-by: Pekka Enberg <penberg@...helsinki.fi>

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