linux-kernel - Re: [PATCH 00/10] jump label: introduce very

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: <20120222065016.GA16923@elte.hu>
Date:	Wed, 22 Feb 2012 07:50:16 +0100
From:	Ingo Molnar <mingo@...e.hu>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	Jason Baron <jbaron@...hat.com>, a.p.zijlstra@...llo.nl,
	rostedt@...dmis.org, mathieu.desnoyers@...icios.com,
	davem@...emloft.net, ddaney.cavm@...il.com,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: [PATCH 00/10] jump label: introduce very_[un]likely + cleanups +
 docs

* H. Peter Anvin <hpa@...or.com> wrote:

> On 02/21/2012 12:02 PM, Jason Baron wrote:
> > Hi,
> > 
> > Renames 'static_branch()' -> very_unlikely(), hopefully, to be more intuitive
> > as to what jump labels is about. I'm also introducing 'very_likely()', as
> > the analogue to very_unlikely(). Patch is against the -tip perf branch.
> > 
> 
> Erk... I'm not happy about this.  very_unlikely() makes it 
> sound like it operates like unlikely(), which really is not 
> the case.  There is a huge difference in mechanism here as 
> well as usage.

There are three issues why I insisted for Jason to rename these 
nonsensically 'jump_label' patterned methods before I send any 
more jump label commits to Linus:

The pattern has spread beyond the niche of tracing internals and 
nobody seemed to have any second thoughts about the actual 
readability of these names. That is a major FAIL and it was my 
primary concern.

For those *reading* the code, the similarity of 
very_likely()/very_unlikely() to the likely()/unlikely() 
patterns is *INTENTIONAL*, as functionally the branch site 
itself is very similar to a real branch!

Secondly, for those *writing* such code, you cannot just 
'accidentally' change a unlikely() to a very_unlikely() and get 
something you didn't ask for ...

It is the modification site that is dissimilar (and which is 
slow in the jump label case) - and that is very apparently 
dissimilar that it takes some effort to change these flags. If 
you write such code you have to add the whole jump label 
mechanism to it, which makes it very apparent what is happening 
and makes the costs very apparent as well.

Thirdly, the fact that it's a 'jump label' is an 
*implementational* detail. On some architectures very_unlikely() 
indeed maps to unlikely(), because jump labels have not been 
implemented yet. On some architectures very_unlikely() is 
implemented via jump labels. On some future architectures it 
might be implemented via JIT-ing the target function. (I made 
the last one up)

So it makes sense to decouple 'jump labels' from the actual high 
level naming of this API.

Anyway, I've Cc:-ed Linus and Andrew, I plan to take the renames 
but they can NAK me if doing that is stupid.

Thanks,

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