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]

Message-ID: <20100921163334.GE2873@redhat.com>
Date:	Tue, 21 Sep 2010 12:33:34 -0400
From:	Jason Baron <jbaron@...hat.com>
To:	Steven Rostedt <rostedt@...dmis.org>
Cc:	Ingo Molnar <mingo@...e.hu>, "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, Sep 21, 2010 at 11:35:24AM -0400, Steven Rostedt wrote:
> 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.
> 

No, OPTIMIZE_FOR_SIZE doesn't break anything, its just that the
'dormant' or the cold code path, isn't moved out of line.

I believe the current approach will eventually lead us to an optimal solution,
(single no-op in the fast path, with ability to jump patch to
out-of-line cold code), even if its not quite there yet under this
compiler flag. And the inclusion of this code will provide more of an
impetus for gcc to make further optimizations.

thanks,

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