linux-kernel - Re: [PATCH UPDATED] percpu: use dynamic percpu allocator as the default percpu allocator

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:	Thu, 02 Apr 2009 11:30:57 +0900
From:	Tejun Heo <tj@...nel.org>
To:	Matthew Wilcox <matthew@....cx>
CC:	Ingo Molnar <mingo@...e.hu>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Christoph Lameter <cl@...ux.com>,
	Martin Schwidefsky <schwidefsky@...ibm.com>,
	rusty@...tcorp.com.au, tglx@...utronix.de, x86@...nel.org,
	linux-kernel@...r.kernel.org, hpa@...or.com,
	Paul Mundt <lethal@...ux-sh.org>, rmk@....linux.org.uk,
	starvik@...s.com, ralf@...ux-mips.org, davem@...emloft.net,
	cooloney@...nel.org, kyle@...artin.ca, grundler@...isc-linux.org,
	takata@...ux-m32r.org, benh@...nel.crashing.org, rth@...ddle.net,
	ink@...assic.park.msu.ru, heiko.carstens@...ibm.com,
	Nick Piggin <npiggin@...e.de>,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCH UPDATED] percpu: use dynamic percpu allocator as the default
 percpu allocator

Matthew Wilcox wrote:
> On Thu, Apr 02, 2009 at 12:32:41AM +0200, Ingo Molnar wrote:
>> And free_percpu(NULL) does this:
>>
>> void free_percpu(void *ptr)
>> {
>>         void *addr = __pcpu_ptr_to_addr(ptr);
>>         struct pcpu_chunk *chunk;
>>         unsigned long flags;
>>         int off;
>>
>>         if (!ptr)
>>                 return;
> 
> Why don't we rewrite this as:
> 
> -	void *addr = __pcpu_ptr_to_addr(ptr);
> +	void *addr;
> ...
> 	if (!ptr)
> 		return;
> 	addr = __pcpu_ptr_to_addr(ptr);
> 
> if kfree(NULL) is really that important, we should avoid doing this
> extra work, not just rely on the variable being cache-hot.

Slightly off-topic but the expectation was that gcc would be smart
enough to optimize it as it sees fit regardless of the actual code
ordering.  The access to the global variable being read, there is no
actual difference between the original code and yours.  Oh well... at
any rate, I don't think it's at the level we should be optimizing at.

Thanks.

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