From mboxrd@z Thu Jan 1 00:00:00 1970 From: "H. Peter Anvin" Subject: Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning Date: Fri, 09 Jan 2009 21:03:01 -0800 Message-ID: <49682C05.7030407@zytor.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 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: Linus Torvalds Return-path: In-Reply-To: List-ID: Linus Torvalds wrote: > > There's none. In fact, it's wrong, unless you _also_ have an extern > definition (according to the "new" gcc rules as of back in the days). > > Of course, as long as "inline" really means _always_ inline, it won't > matter. So in that sense Ingo is right - we _could_. Which has no bearing > on whether we _should_, of course. > 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. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf.