linux-kernel - Re: [PATCH 08/10] jump label v11: x86 support

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:	Tue, 21 Sep 2010 11:35:24 -0400
From:	Steven Rostedt <rostedt@...dmis.org>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Jason Baron <jbaron@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
	linux-kernel@...r.kernel.org, mathieu.desnoyers@...ymtl.ca,
	tglx@...utronix.de, andi@...stfloor.org, roland@...hat.com,
	rth@...hat.com, mhiramat@...hat.com, fweisbec@...il.com,
	avi@...hat.com, davem@...emloft.net, vgoyal@...hat.com,
	sam@...nborg.org, tony@...eyournoodle.com
Subject: Re: [PATCH 08/10] jump label v11: x86 support

On Tue, 2010-09-21 at 17:29 +0200, Ingo Molnar wrote:

> > >From the documentation patch:
> > 
> > " The optimization depends on !CC_OPTIMIZE_FOR_SIZE. When 
> > CC_OPTIMIZE_FOR_SIZE is set, gcc does not always out of line the not 
> > taken label path in the same way that the "if unlikely()" paths are 
> > made out of line. Thus, with CC_OPTIMIZE_FOR_SIZE set, this 
> > optimization is not always optimal. This may be solved in subsequent 
> > gcc versions, that allow us to move labels out of line, while still 
> > optimizing for size. "
> 
> OTOH making a difficult optimization (HAVE_ARCH_JUMP_LABEL) dependent on 
> compiler flags is really asking for trouble.
> 
> So how about enabling it unconditionally, and just chalk up the cost 
> under CC_OPTIMIZE_FOR_SIZE as one of the costs it already has? This also 
> has the advantage that future compilers can improve things without 
> having to wait for yet another kernel patch that re-enables 
> HAVE_ARCH_JUMP_LABEL.

Agreed,

CC_OPTIMIZE_FOR_SIZE does not mean OPTIMIZE_FOR_PERFORMANCE. Although
people have argued that with smaller size you gain better cache
performance. I've noticed that the general case is that optimizing for
size has decreased performance (although I have not done any official
benchmarks, just my own personal observations).

I thought you may have had that there because OPTIMIZE_FOR_SIZE actually
broke the code (as some gcc compilers do for function graph tracer). If
its just a "we don't perform better with this set". Then get rid of it.

Thanks,

-- Steve


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