From mboxrd@z Thu Jan 1 00:00:00 1970 From: Linus Torvalds Subject: Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning Date: Fri, 9 Jan 2009 21:28:01 -0800 (PST) Message-ID: References: <4966AB74.2090104@zytor.com> <20090109133710.GB31845@elte.hu> <20090109204103.GA17212@elte.hu> <20090109213442.GA20051@elte.hu> <1231537320.5726.2.camel@brick> <20090109231227.GA25070@elte.hu> <20090110010125.GA31031@elte.hu> <1231549697.5700.7.camel@brick> <49682C05.7030407@zytor.com> Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Harvey Harrison , Ingo Molnar , Andi Kleen , Chris Mason , Peter Zijlstra , Steven Rostedt , paulmck@linux.vnet.ibm.com, Gregory Haskins , Matthew Wilcox , Andrew Morton , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich , Heiko Carstens To: "H. Peter Anvin" Return-path: In-Reply-To: <49682C05.7030407@zytor.com> List-ID: On Fri, 9 Jan 2009, H. Peter Anvin wrote: > > I was thinking about experimenting with this, to see what level of > upside it might add. Ingo showed me numbers which indicate that a > fairly significant fraction of the cases where removing inline helps is > in .h files, which would require code movement to fix. Hence to see if > it can be automated. We _definitely_ have too many inline functions in headers. They usually start out small, and then they grow. And even after they've grown big, it's usually not at all clear exactly where else they should go, so even when you realize that "that shouldn't be inlined", moving them and making them uninlined is not obvious. And quite often, some of them go away - or at least shrink a lot - when some config option or other isn't set. So sometimes it's an inline because a certain class of people really want it inlined, simply because for _them_ it makes sense, but when you enable debugging or something, it absolutely explodes. Linus