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] [day] [month] [year] [list]
Message-ID: <20090924191642.GA19225@elte.hu>
Date:	Thu, 24 Sep 2009 21:16:42 +0200
From:	Ingo Molnar <mingo@...e.hu>
To:	Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca>
Cc:	Jason Baron <jbaron@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Steven Rostedt <rostedt@...dmis.org>, Andi Kleen <ak@...e.de>,
	linux-kernel@...r.kernel.org
Subject: Re: Immediate values


* Mathieu Desnoyers <mathieu.desnoyers@...ymtl.ca> wrote:

> * Jason Baron (jbaron@...hat.com) wrote:
> > 
> > right we've proposed an alternative to the immediate values, which 
> > I've been calling 'jump label', here:
> > 
> > http://marc.info/?l=linux-kernel&m=125200966226921&w=2
> > 
> > The basic idea is that gcc, 4.5 will have support for an 'asm goto' 
> > construct which can refer to c code labels. Thus, we can replace a 
> > nop in the code stream with a 'jmp' instruction to various branch 
> > targets.
> > 
> > In terms of a comparison between the two, IMO, I think that the 
> > syntax for the immediate variables can be more readable, since it 
> > just looks like a conditional expression.
> > 
> > The immediate values do a 'mov', 'test' and then a jump, whereas 
> > jump label can just do a jump. So in this respect, I believe jump 
> > label can be more optimal. Additinally, if we want to mark sections 
> > 'cold' so they don't impact the istruction cache, the jump label 
> > already has the labels for doing so. Obviously, a performance 
> > comparison would be interesting as well.
> 
> For branches, I'm convinced that a "static jump" approach will beat 
> immediate values anytime, because you save the BPB hit completely.
> 
> However, there are other use-cases involving a variable read, and in 
> that case immediate values are useful. Andi has been bugging me for a 
> while to re-post this patchset, I'm pretty sure he has precise ideas 
> about how he would like to use it.

It depends on how significant that usecase is.

Tracepoints used to be the biggest use-case for immediate values, and 
without that the thing becomes rather complex to maintain, for probably 
very little benefit.

	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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ