linux-kernel - Re: [2.6 patch] kernel/sched*: optimize inlining

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: <20080511200016.GH1645@cs181133002.pp.htv.fi>
Date:	Sun, 11 May 2008 23:00:16 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Sam Ravnborg <sam@...nborg.org>
Cc:	mingo@...e.hu, linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [2.6 patch] kernel/sched*: optimize inlining

On Sun, May 11, 2008 at 09:42:48PM +0200, Sam Ravnborg wrote:
> On Sun, May 11, 2008 at 09:49:52PM +0300, Adrian Bunk wrote:
> > On Sun, May 11, 2008 at 07:52:22PM +0200, Sam Ravnborg wrote:
>...
> > > The last line "no inline(hint)" is with Adrians patch applied.
> > > So what is obvious from the above is that with the arch/gcc combination
> > > I use here the inline hint has a clear effect and gcc inlines more
> > > when we have given it a hint to do so than without the hint.
> > > I conclude this solely on the cide size change between the line
> > > "inline hint" and "no inline(hint)".
> > > 
> > > With adrians patch there were no difference in size with or
> > > without the OPTIMIZE_INLINING enabled.
> > > 
> > > Or in other words the config option "OPTIMIZE_INLINING" is NOT
> > > equal to removing all the inline annotations.
> > 
> > Both do the same with the same justification:
> > 
> > Both give the decision whether or not to inline completely into the 
> > hands of gcc, which can make different inlining decisions depending on 
> > e.g. the gcc version and the CONFIG_CC_OPTIMIZE_FOR_SIZE setting, and
> > the only thing benchmarked is the code size.
> 
> You continue to fail to acknowledge that it is valueable information
> that we pass gcc a _hint_ that it is a good idea to inline certain
> functions.
> 
> The inline hint is there to tell gcc that it shall inline this function
> in cases where it usual think it should not do so. Which invietably
> will result in a larger codesize in some cases.

We also give gcc an explicit "Optimize for size.".

Do you expect any well-defined behaviour across different gcc versions  
when giving gcc such conflicting information?

If gcc would decide to ignore all hints that increase code size with -Os 
that would be perfectly fine behaviour.

All the "optimized inlining" does is to allow gcc to no longer inline 
functions marked as "inline" if it prefers not to do so.

And what exactly is your problem with my patch if you consider the 
general "optimized inlining" approach correct?

After all, the 2.3% textsize reduction that justified the "optimized 
inlining" comes exactly from the cases where gcc does no longer obey
the "it shall inline this function" hint.

> 	Sam

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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