From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Morton Subject: Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning Date: Fri, 9 Jan 2009 17:41:58 -0800 Message-ID: <20090109174158.096dee70.akpm@linux-foundation.org> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Cc: Linus Torvalds , Harvey Harrison , "H. Peter Anvin" , Andi Kleen , Chris Mason , Peter Zijlstra , Steven Rostedt , paulmck@linux.vnet.ibm.com, Gregory Haskins , Matthew Wilcox , Linux Kernel Mailing List , linux-fsdevel , linux-btrfs , Thomas Gleixner , Nick Piggin , Peter Morreale , Sven Dietrich To: Ingo Molnar Return-path: In-Reply-To: <20090110010125.GA31031@elte.hu> List-ID: On Sat, 10 Jan 2009 02:01:25 +0100 Ingo Molnar wrote: > > * Linus Torvalds wrote: > > > On Sat, 10 Jan 2009, Ingo Molnar wrote: > > > > > > may_inline/inline_hint is a longer, less known and uglier keyword. > > > > Hey, your choice, should you decide to accept it, is to just get rid of > > them entirely. > > > > You claim that we're back to square one, but that's simply the way > > things are. Either "inline" means something, or it doesn't. You argue > > for it meaning nothing. I argue for it meaning something. > > > > If you want to argue for it meaning nothing, then REMOVE it, instead of > > breaking it. > > > > It really is that simple. Remove the inlines you think are wrong. > > Instead of trying to change the meaning of them. > > Well, it's not totally meaningless. To begin with, defining 'inline' to > mean 'always inline' is a Linux kernel definition. So we already changed > the behavior - in the hope of getting it right most of the time and in the > hope of thus improving the kernel. > > And now it appears that in our quest of improving the kernel we can > further tweak that (already non-standard) meaning to a weak "inline if the > compiler agrees too" hint. That gives us an even more compact kernel. It > also moves the meaning of 'inline' closer to what the typical programmer > expects it to be - for better or worse. > > We could remove them completely, but there are a couple of practical > problems with that: > > - In this cycle alone, in the past ~2 weeks we added another 1300 inlines > to the kernel. Who "reviewed" all that? > Do we really want periodic postings of: > > [PATCH 0/135] inline removal cleanups > > ... in the next 10 years? We have about 20% of all functions in the > kernel marked with 'inline'. It is a _very_ strong habit. Is it worth > fighting against it? A side-effect of the inline fetish is that a lot of it goes into header files, thus requiring that those header files #include lots of other headers, thus leading to, well, the current mess.