linux-kernel - Re: [PATCH 1/1] mm: unify pmd

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: <alpine.LFD.1.10.0807281000070.3486@nehalem.linux-foundation.org>
Date:	Mon, 28 Jul 2008 10:10:19 -0700 (PDT)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
cc:	Andrea Righi <righi.andrea@...il.com>, akpm@...ux-foundation.org,
	linux-mm@...ck.org, linux-arch@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/1] mm: unify pmd_free() implementation

On Mon, 28 Jul 2008, James Bottomley wrote:
> 
> Sorry ... should have been clearer.  My main concern is the cost of
> barrier() which is just a memory clobber ... we have to use barriers to
> place the probe points correctly in the code.

Oh, "barrier()" itself has _much_ less cost.

It still has all the "needs to flush any global/address-taken-of variables 
to memory" property and can thus cause reloads, but that's kind of the 
point of it, after all. So in that sense "barrier()" is free: the only 
cost of a barrier is the cost of what you actually need to get done. It's 
not really "free", but it's also not any more costly than what your 
objective was.

In contrast, the "objective" in an empty function call is seldom the 
serialization, so in that case the serialization is all just unnecessary 
overhead.

Also, barrier() avoids the big hit of turning a leaf function into a 
non-leaf one. It also avoids all the fixed registers and the register 
clobbers (although for tracing purposes you may end up setting up fixed 
regs, of course).

The leaf -> non-leaf thing is actually often the major thing. Yes, the 
compiler will often inline functions that are simple enough to be leaf 
functions with no stack frame, so we don't have _that_ many of them, but 
when it hits, it's often the most noticeable part of an unnecessary 
function call. And "barrier()" should never trigger that problem.

			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/