linux-kernel - Re: CONFIG_OPTIMIZE

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: <Pine.LNX.4.64.0811141244060.29394@quilx.com>
Date:	Fri, 14 Nov 2008 12:53:13 -0600 (CST)
From:	Christoph Lameter <cl@...ux-foundation.org>
To:	Hugh Dickins <hugh@...itas.com>
cc:	Ingo Molnar <mingo@...e.hu>, Nick Piggin <nickpiggin@...oo.com.au>,
	linux-kernel@...r.kernel.org
Subject: Re: CONFIG_OPTIMIZE_INLINING fun

On Fri, 14 Nov 2008, Hugh Dickins wrote:

> --- 2.6.28-rc4/arch/x86/Kconfig.debug	2008-10-24 09:27:47.000000000 +0100
> +++ linux/arch/x86/Kconfig.debug	2008-11-14 16:26:15.000000000 +0000
> @@ -302,6 +302,7 @@ config CPA_DEBUG
>
>  config OPTIMIZE_INLINING
>  	bool "Allow gcc to uninline functions marked 'inline'"
> +	depends on !CC_OPTIMIZE_FOR_SIZE
>  	help
>  	  This option determines if the kernel forces gcc to inline the functions
>  	  developers have marked 'inline'. Doing so takes away freedom from gcc to
>

Maybe add some text explaining that this is some experimental gcc feature?

> You'll be amused to see the asm for this example from mm/swap_state.c
> (I was intending to downgrade these BUG_ONs to VM_BUG_ONs anyway, but
> this example makes that seem highly desirable):
>
> void __delete_from_swap_cache(struct page *page)
> {
> 	BUG_ON(!PageLocked(page));
> 	BUG_ON(!PageSwapCache(page));
> 	BUG_ON(PageWriteback(page));
> 	BUG_ON(PagePrivate(page));

Maybe checking all the conditionals in one BUG_ON is not such a bad idea
after all? 4 useless branches in a hotpath?

> Here's the nice asm 4.2.1 gives with just CONFIG_CC_OPTIMIZE_FOR_SIZE=y
> (different machine, this one a laptop with CONFIG_VMSPLIT_2G_OPT=y):

Optimize for size is what I also have usually on. Inline "optimization"
never worked as far as I can tell so I usually have that off.

> I do wonder whether there's some tweak we could make to page-flags.h
> which would stop this nonsense.  Change the inline functions back to
> macros?  I suspect that by itself wouldn't work, and my quick attempt
> to try it failed abysmally to compile, I've not the cpp foo needed.

I think we want to get away from macros as much as possible.

> A part of the problem may be that test_bit() etc. are designed for
> arrays of unsigned longs, but page->flags is only the one unsigned long:
> maybe gcc loses track of the optimizations available for that case when
> CONFIG_OPTIMIZE_INLINING=y.
>
> Hah, I've just noticed the defaults in arch/x86/configs -
> you might want to change those...

Argh.. Yes.... CONFIG_OPTIMIZE_INLINING must only be enabled if the
compiler can actually create a benefit from optimizing the
inlining. That could be in gcc 4.5 or so I guess.
--
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/