linux-kernel - Re: [patch] measurements, numbers about 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: <alpine.LFD.2.00.0901091145110.6528@localhost.localdomain>
Date:	Fri, 9 Jan 2009 11:48:41 -0800 (PST)
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	Matthew Wilcox <matthew@....cx>
cc:	Andi Kleen <andi@...stfloor.org>,
	Dirk Hohndel <hohndel@...radead.org>,
	"H. Peter Anvin" <hpa@...or.com>, Ingo Molnar <mingo@...e.hu>,
	jim owens <jowens@...com>,
	Chris Mason <chris.mason@...cle.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	paulmck@...ux.vnet.ibm.com, Gregory Haskins <ghaskins@...ell.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	linux-btrfs <linux-btrfs@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Nick Piggin <npiggin@...e.de>,
	Peter Morreale <pmorreale@...ell.com>,
	Sven Dietrich <SDietrich@...ell.com>, jh@...e.cz
Subject: Re: [patch] measurements, numbers about CONFIG_OPTIMIZE_INLINING=y
 impact



On Fri, 9 Jan 2009, Matthew Wilcox wrote:
> 
> Now, I'm not going to argue the directIO code is a shining example of
> how we want things to look, but we don't really want ten arguments
> being marshalled into a function call; we want gcc to inline the
> direct_io_worker() and do its best to optimise the whole thing.

Well, except we quite probably would be happier with gcc not doing that, 
than with gcc doing that too often.

There are exceptions. If the caller is really small (ie a pure wrapper 
that perhaps just does some locking around the call), then sure, inlining 
a large function that only gets called from one place does make sense.

But if both the caller and the callee is large, like in your example, then 
no. DON'T INLINE IT. Unless we _tell_ you, of course, which we probably 
shouldn't do.

Why? Becuase debugging is more important. And deciding to inline that, you 
probably decided to inline something _else_ too. And now you've quite 
possibly blown your stackspace.

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