[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090109215822.GA21613@elte.hu>
Date: Fri, 9 Jan 2009 22:58:22 +0100
From: Ingo Molnar <mingo@...e.hu>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: "H. Peter Anvin" <hpa@...or.com>, Andi Kleen <andi@...stfloor.org>,
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>,
Matthew Wilcox <matthew@....cx>,
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>
Subject: Re: [PATCH -v7][RFC]: mutex: implement adaptive spinning
* Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> On Fri, 9 Jan 2009, Ingo Molnar wrote:
> >
> > So, should we not remove CONFIG_OPTIMIZE_INLINING, then the correct one
> > would be to mark it __always_inline [__asm_inline is senseless there], or
> > the second patch below that changes the bit parameter to unsigned int.
>
> Well, I certainly don't want to _remove_ the "inline" like your patch did.
hm, that was a bug that i noticed and fixed in the second, fuller version
of the patch i sent - which converts all the 'int nr' instances in
bitops.h to 'unsigned int nr'.
This is the only instance where the integer type of 'nr' matters in
practice though, due to the modulo arithmetics. But for cleanliness
reasons we want to do the full patch, to have a standard type signature
for these bitop methods.
> Other gcc versions will care. But I committed the pure "change to
> unsigned" part.
thanks! I'll clean up the rest - the second patch will now conflict
(trivially). I also wanted to check the whole file more fully, there might
be other details. [ So many files, so few nights ;-) ]
We also might need more __always_inline's here and in other places, to
solve the nonsensical inlining problems that Chris's case showed for
example, with earlier GCCs.
Another option would be to not trust earlier GCCs at all with this feature
- to only define inline to not-__always_inline only on latest 4.3.x GCC -
the only one that seems to at least not mess up royally.
Thus CONFIG_OPTIMIZE_INLINING=y would have no effect on older GCCs. That
would quarantine the problem (and the impact) sufficiently i think. And if
future GCCs start messing up in this area we could zap the whole feature
in a heartbeat.
( Although now that we have this feature this gives an incentive to
compiler folks to tune their inliner on to the Linux kernel - for a
decade we never allowed them to do that. The kernel clearly has one of
the trickiest (and ugliest) inlining smarts in headers - and we never
really exposed compilers to those things, so i'm not surprised at all
that they mess up in cases.
Unfortunately the version lifecycle of most compiler projects is
measured in years, not in months like that of the kernel. There's many
reasons for that - and not all of those reasons are strictly their
fault. )
Ingo
--
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/
Powered by blists - more mailing lists