Ingo Molnar wrote:
>
> - Headers could probably go back to 'extern inline' again. At not small
>expense - we just finished moving to 'static inline'. We'd need to
>guarantee a library instantiation for every header include file - this
>is an additional mechanism with additional int
On Fri, 2009-01-09 at 20:05 -0800, Linus Torvalds wrote:
>
> On Fri, 9 Jan 2009, Nicholas Miell wrote:
> >
> > It's only too big if you always keep it in memory, and I wasn't
> > suggesting that.
>
> Umm. We're talking kernel panics here. If it's not in memory, it doesn't
> exist as far as the
Arjan van de Ven wrote:
>
> thinking about this.. making a "pastebin" like thing for oopses is
> relatively trivial for me; all the building blocks I have already.
>
> The hard part is getting the vmlinux files in place. Right now I do
> this manually for popular released kernels.. if the fedora/
Linus Torvalds wrote:
>
> 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 debu
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
On Fri, 9 Jan 2009 14:52:33 -0500
Theodore Tso wrote:
> Kerneloops.org does this, so the code is mostly written; but it does
> this in a blinded fashion, so it only makes sense for oops which are
> very common and for which we don't need to ask the user, "so what were
> you doing at the time". I
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_.
On Fri, 9 Jan 2009, Nicholas Miell wrote:
>
> It's only too big if you always keep it in memory, and I wasn't
> suggesting that.
Umm. We're talking kernel panics here. If it's not in memory, it doesn't
exist as far as the kernel is concerned.
If it doesn't exist, it cannot be reported.
> My
> 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.
I personally also always found it annoying while grepping that
part of the code is in a completely di
On Fri, 2009-01-09 at 16:05 -0800, Linus Torvalds wrote:
>
> On Fri, 9 Jan 2009, Nicholas Miell wrote:
>
> > In the general case is it does nothing at all to debugging (beyond the
> > usual weird control flow you get from any optimized code) -- the
> > compiler generates line number information f
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
> >
On Sat, 10 Jan 2009, Ingo Molnar wrote:
>
> - 'static inline' functions in .c files that are not used cause no build
>warnings - while if we change them to 'static', we get a 'defined but
>not used' warning. Hundreds of new warnings in the allyesconfig builds.
Well, duh. Maybe they sh
On Sat, 10 Jan 2009, Ingo Molnar wrote:
>
> * Linus Torvalds wrote:
>
> > On Sat, 10 Jan 2009, Ingo Molnar wrote:
> > >
> > > 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 beh
On Fri, 9 Jan 2009, Harvey Harrison wrote:
> On Sat, 2009-01-10 at 02:01 +0100, Ingo Molnar wrote:
>
> > - Headers could probably go back to 'extern inline' again. At not small
> >expense - we just finished moving to 'static inline'. We'd need to
> >guarantee a library instantiation
* Linus Torvalds wrote:
> On Sat, 10 Jan 2009, Ingo Molnar wrote:
> >
> > 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 an
> - Headers could probably go back to 'extern inline' again. At not small
>expense - we just finished moving to 'static inline'. We'd need to
>guarantee a library instantiation for every header include file - this
>is an additional mechanism with additional introduction complexitie
On Sat, 2009-01-10 at 02:01 +0100, Ingo Molnar wrote:
> * Linus Torvalds wrote:
> - Headers could probably go back to 'extern inline' again. At not small
>expense - we just finished moving to 'static inline'. We'd need to
>guarantee a library instantiation for every header include file
On Sat, 10 Jan 2009, Ingo Molnar wrote:
>
> 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
On Sat, 10 Jan 2009, Jamie Lokier wrote:
>
> Does "always_inline" complain if the function isn't inlinable, while
> "inline" allows it? That would explain the alpha comment.
I suspect it dates back to gcc-3.1 days. It's from 2004. And the author of
that comment is a part-time gcc hacker who w
Hello everyone,
Just a quick note that Linus merged the btrfs unstable repository into
the mainline kernel. I'll cut a new stable release of btrfs-progs on
Monday to go with it (for now the unstable repo is the best choice).
I'd like to thank everyone who contributed to the code, tested,
reviewe
* 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 si
On Sat, Jan 10, 2009 at 12:53:42AM +, Jamie Lokier wrote:
> Harvey Harrison wrote:
> > Oh yeah, and figure out what actually breaks on alpha such that they added
> > the following (arch/alpha/include/asm/compiler.h)
> >
> > #ifdef __KERNEL__
> > /* Some idiots over in thought inline should im
> I thought -Os actually disabled the basic-block reordering, doesn't it?
Not in current gcc head no (just verified by stepping through)
>
> And I thought it did that exactly because it generates bigger code and
> much worse I$ patterns (ie you have a lot of "conditional branch to other
> pla
Harvey Harrison wrote:
> Oh yeah, and figure out what actually breaks on alpha such that they added
> the following (arch/alpha/include/asm/compiler.h)
>
> #ifdef __KERNEL__
> /* Some idiots over in thought inline should imply
>always_inline. This breaks stuff. We'll include this file whene
On Sat, 10 Jan 2009, Andi Kleen wrote:
>
> > What's the cost/benefit of that 4%? Does it actually improve performance?
> > Especially if you then want to keep DWARF unwind information in memory in
> > order to fix up some of the problems it causes? At that point, you lost
>
> dwarf unwind inf
> What's the cost/benefit of that 4%? Does it actually improve performance?
> Especially if you then want to keep DWARF unwind information in memory in
> order to fix up some of the problems it causes? At that point, you lost
dwarf unwind information has nothing to do with this, it doesn't tell
On Fri, 9 Jan 2009, Nicholas Miell wrote:
>
> So take your complaint about gcc's decision to inline functions called
> once.
Actually, the "called once" really is a red herring. The big complaint is
"too aggressively when not asked for". It just so happens that the called
once logic is right
On Fri, Jan 09, 2009 at 11:44:10PM +0100, Andi Kleen wrote:
> > Fetch a gigabyte's worth of data for the debuginfo RPM?
>
> The suse 11.0 kernel debuginfo is ~120M.
How is this debuginfo generated?
Someone have posted the following patch which I did not apply in lack
of any real need. But maybe
On Fri, 2009-01-09 at 12:29 -0800, Linus Torvalds wrote:
>
> On Fri, 9 Jan 2009, Nicholas Miell wrote:
> >
> > Maybe the kernel's backtrace code should be fixed instead of blaming
> > gcc.
>
> And maybe people who don't know what they are talking about shouldn't
> speak?
I may not know what I'
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
* Linus Torvalds wrote:
> On Fri, 9 Jan 2009, Harvey Harrison wrote:
> >
> > __needs_inline? That would imply that it's for correctness reasons.
>
> .. but the point is, we have _thousands_ of inlines, and do you know
> which is which? We've historically forced them to be inlined, and every
On Fri, 09 Jan 2009 14:35:29 -0800
"H. Peter Anvin" wrote:
> Andi Kleen wrote:
> >> Fetch a gigabyte's worth of data for the debuginfo RPM?
> >
> > The suse 11.0 kernel debuginfo is ~120M.
>
> Still, though, hardly worth doing client-side when it can be done
> server-side for all the common d
Andi Kleen wrote:
Fetch a gigabyte's worth of data for the debuginfo RPM?
The suse 11.0 kernel debuginfo is ~120M.
Still, though, hardly worth doing client-side when it can be done
server-side for all the common distro kernels. For custom kernels, not
so, but there you should already have
> Fetch a gigabyte's worth of data for the debuginfo RPM?
The suse 11.0 kernel debuginfo is ~120M.
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.
On Fri, 2009-01-09 at 14:09 -0800, Linus Torvalds wrote:
> Actually, the nice part about "inline_hint" would be that then we could
> have some nice config option like
>
> #ifdef CONFIG_FULL_CALL_TRACE
>#define inline_hint noinline
> #elif defined(CONFIG_TRUST_COMPILER)
>#define inline
Chris:
I can consistently reproduce I/O stalls when running fstress (as found
in Autotest) against a six volume btrfs filesystem mounted without
options. The volumes are independent disks from RAID controllers, and
the test systems are eight core Intel and AMD machines running current
btrfs-
On Fri, 2009-01-09 at 14:09 -0800, Linus Torvalds wrote:
> We have a few users of "__inline", but not very many. We can leave them
> alone, or just convert them to __inline__ or inline.
Actually I sent out a series of patches which mostly went in 2.6.27-28
timeframe, that's why there's a lot few
On Fri, 9 Jan 2009, Harvey Harrison wrote:
> >
> > Of course, at that point you might as well argue that the thing should not
> > exist at all, and that such a flag should just be removed entirely. Which
> > I certainly agree with - I think the only flag we need is "inline", and I
> > think i
On Fri, 9 Jan 2009 14:52:33 -0500
Theodore Tso wrote:
> On Fri, Jan 09, 2009 at 07:55:09PM +0100, Andi Kleen wrote:
> > > But _users_ just get their oopses sent automatically. So it's not
> > > about
> >
> > If they send it from distro kernels the automated oops sender could
> > just fetch the
On Fri, 2009-01-09 at 13:50 -0800, Linus Torvalds wrote:
>
> On Fri, 9 Jan 2009, Harvey Harrison wrote:
> >
> > __needs_inline? That would imply that it's for correctness reasons.
>
> .. but the point is, we have _thousands_ of inlines, and do you know which
> is which? We've historically forc
* Linus Torvalds 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
On Fri, 9 Jan 2009, Harvey Harrison wrote:
>
> __needs_inline? That would imply that it's for correctness reasons.
.. but the point is, we have _thousands_ of inlines, and do you know which
is which? We've historically forced them to be inlined, and every time
somebody does that "OPTIMIZE_IN
On Fri, 9 Jan 2009, Ingo Molnar wrote:
>
> - Perhaps we could introduce a name for the first category: __must_inline?
> __should_inline? Not because it wouldnt mean 'always', but because it is
> 'always inline' for another reason than the correctless __always_inline.
I think you're thinki
On Fri, 2009-01-09 at 22:34 +0100, Ingo Molnar wrote:
> The naming problem remains though:
>
> - Perhaps we could introduce a name for the first category: __must_inline?
> __should_inline? Not because it wouldnt mean 'always', but because it is
> 'always inline' for another reason than the c
On Fri, 9 Jan 2009, Theodore Tso wrote:
> I'm beginning to think that for the kernel, we should just simply
> remove CONFIG_OPTIMIZE_INLINING (so that inline means
> "always_inline"), and -fno-inline-functions
> -fno-inline-functions-called-one (so that gcc never inlines functions
> behind our ba
* Linus Torvalds 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
> > unsi
I'm beginning to think that for the kernel, we should just simply
remove CONFIG_OPTIMIZE_INLINING (so that inline means
"always_inline"), and -fno-inline-functions
-fno-inline-functions-called-one (so that gcc never inlines functions
behind our back) --- and then we create tools that count how many
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
> I've done a finegrained size analysis today (see my other mail in this
> thread), and it turns out that on gcc 4.3.x the main (and pretty much
> only) inlining annotation that matters in arch/x86/include/asm/*.h is the
> onliner patch attached below, annotating constant_test_bit().
That's pre
* Ingo Molnar wrote:
> Note that meanwhile i also figured out why gcc got the inlining wrong
> there: the 'int nr' combined with the '% BITS_PER_LONG' signed
> arithmetics was too much for it to figure out at the inlining stage - it
> generated IDIV instructions, etc. With forced inlining lat
>
> And you do have to realize that Linux has been using gcc for a _loong_
> while. You can talk all you want about how "inline" is just a hint, but
> the fact is, it didn't use to be. gcc people _made_ it so, and are having
> a damn hard time admitting that it's causing problems.
The kernel h
* Linus Torvalds wrote:
> On Fri, 9 Jan 2009, Ingo Molnar wrote:
> >
> > -static inline int constant_test_bit(int nr, const volatile unsigned long
> > *addr)
> > +static __asm_inline int
> > +constant_test_bit(int nr, const volatile unsigned long *addr)
> > {
> > return ((1UL << (nr % BI
On Fri, Jan 9, 2009 at 9:26 PM, Linus Torvalds
wrote:
>
>
> On Fri, 9 Jan 2009, Richard Guenther wrote:
>>
>> This is a case where the improved IPA-CP (interprocedural constant
>> propagation) of GCC 4.4 may help. In general GCC cannot say how a call
>> argument may affect optimization if the fun
On Fri, 9 Jan 2009, Nicholas Miell wrote:
>
> Maybe the kernel's backtrace code should be fixed instead of blaming
> gcc.
And maybe people who don't know what they are talking about shouldn't
speak?
You just loaded the whole f*cking debug info just to do that exact
analysis. Guess how big it
On Fri, 9 Jan 2009, Nicholas Miell wrote:
> On Fri, 2009-01-09 at 08:28 -0800, Linus Torvalds wrote:
> >
> > We get oopses that have a nice symbolic back-trace, and it reports an
> > error IN TOTALLY THE WRONG FUNCTION, because gcc "helpfully" inlined
> > things to the point that only an exper
On Fri, 9 Jan 2009, Richard Guenther wrote:
>
> This is a case where the improved IPA-CP (interprocedural constant
> propagation) of GCC 4.4 may help. In general GCC cannot say how a call
> argument may affect optimization if the function was inlined, so the
> size estimates are done with ju
On Fri, 2009-01-09 at 08:28 -0800, Linus Torvalds wrote:
>
> We get oopses that have a nice symbolic back-trace, and it reports an
> error IN TOTALLY THE WRONG FUNCTION, because gcc "helpfully" inlined
> things to the point that only an expert can realize "oh, the bug was
> actually five hundre
On Fri, Jan 9, 2009 at 8:44 PM, Linus Torvalds
wrote:
>
>
> On Fri, 9 Jan 2009, Richard Guenther wrote:
>>
>> -fno-inline-functions-called-once disables the heuristic that always
>> inlines (static!) functions that are called once. Other heuristics
>> still apply, like inlining the static functio
Linus Torvalds wrote:
Because then they are _our_ mistakes, not some random compiler version that
throws a dice!
This does bring up the idea of including a compiler with the kernel
sources again, doesn't it?
-hpa (ducks & runs)
--
To unsubscribe from this list: send the line "unsub
On Fri, Jan 09, 2009 at 07:55:09PM +0100, Andi Kleen wrote:
> > But _users_ just get their oopses sent automatically. So it's not about
>
> If they send it from distro kernels the automated oops sender could
> just fetch the debuginfo rpm and decode it down to a line.
> My old automatic user segf
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 opti
On Fri, 9 Jan 2009, Richard Guenther wrote:
>
> -fno-inline-functions-called-once disables the heuristic that always
> inlines (static!) functions that are called once. Other heuristics
> still apply, like inlining the static function if it is small.
> Everything else would be totally stupi
On Fri, Jan 9, 2009 at 8:40 PM, Andi Kleen wrote:
> On Fri, Jan 09, 2009 at 08:10:20PM +0100, Richard Guenther wrote:
>> On Fri, Jan 9, 2009 at 8:21 PM, Andi Kleen wrote:
>> >> GCC 4.3 should be good in compiling the
>> >> kernel with default -Os settings.
>> >
>> > It's unfortunately not. It doe
On Fri, Jan 09, 2009 at 08:35:06PM +0100, Andi Kleen wrote:
> - Also inline everything static that is only called once
> [on the theory that this shrinks code size which is true
> according to my measurements]
>
> -fno-inline-functions-called once disables this new rule.
> It's very well and clear
On Fri, Jan 09, 2009 at 08:10:20PM +0100, Richard Guenther wrote:
> On Fri, Jan 9, 2009 at 8:21 PM, Andi Kleen wrote:
> >> GCC 4.3 should be good in compiling the
> >> kernel with default -Os settings.
> >
> > It's unfortunately not. It doesn't inline a lot of simple asm() inlines
> > for example.
Richard Guenther wrote:
On Fri, Jan 9, 2009 at 8:21 PM, Andi Kleen wrote:
GCC 4.3 should be good in compiling the
kernel with default -Os settings.
It's unfortunately not. It doesn't inline a lot of simple asm() inlines
for example.
Reading Ingos posting with the actual numbers states the op
> What happens when you say -fno-inline-functions-called-once? Does it
> disable inlining for those functions IN GENERAL, or just for the LARGE
It does disable it in general, unless they're marked inline explicitely :
The traditional gcc 2.x rules were:
I Only inline what is marked inline (but
Richard Guenther wrote:
But it's also not inconceivable that gcc adds a -fkernel-inlining or
similar that changes the parameters if we ask nicely. I suppose
actually such a parameter would be useful for far more programs
than the kernel.
I think that the kernel is a perfect target to optimize
On Fri, Jan 9, 2009 at 8:21 PM, Andi Kleen wrote:
>> GCC 4.3 should be good in compiling the
>> kernel with default -Os settings.
>
> It's unfortunately not. It doesn't inline a lot of simple asm() inlines
> for example.
Reading Ingos posting with the actual numbers states the opposite.
Richard.
On Fri, Jan 9, 2009 at 6:54 PM, Linus Torvalds
wrote:
>
>
> On Fri, 9 Jan 2009, Matthew Wilcox wrote:
>>
>> That seems like valuable feedback to give to the GCC developers.
>
> Well, one thing we should remember is that the kernel really _is_ special.
(sorry for not threading properly here)
Linu
> GCC 4.3 should be good in compiling the
> kernel with default -Os settings.
It's unfortunately not. It doesn't inline a lot of simple asm() inlines
for example.
-Andi
--
a...@linux.intel.com
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to
On Fri, 9 Jan 2009, Andi Kleen wrote:
>
> Ok you're saying we should pay the 4.1% by default for this?
The thing is, YOU ARE MAKING THAT NUMBER UP!
First off, the size increase only matters if it actually increases the
cache footprint. And it may, but..
Secondly, my whole point here has been
On Fri, Jan 9, 2009 at 7:19 PM, Andi Kleen wrote:
>> So we do have special issues. And exactly _because_ we have special issues
>> we should also expect that some compiler defaults simply won't ever really
>> be appropriate for us.
>
> I agree that the kernel needs quite different inlining heurist
> But _users_ just get their oopses sent automatically. So it's not about
If they send it from distro kernels the automated oops sender could
just fetch the debuginfo rpm and decode it down to a line.
My old automatic user segfault uploader I did originally
for the core pipe code did that too.
>
On Fri, 9 Jan 2009, Peter Zijlstra wrote:
>
> On that note:
>
> Index: linux-2.6/kernel/mutex.c
> ===
> --- linux-2.6.orig/kernel/mutex.c
> +++ linux-2.6/kernel/mutex.c
> @@ -220,7 +220,9 @@ __mutex_lock_common(struct mutex *lock,
On Fri, 2009-01-09 at 11:44 -0500, Steven Rostedt wrote:
> When we get to the schedule() it then needs to be a:
>
> preempt_enable_no_resched();
> schedule();
On that note:
Index: linux-2.6/kernel/mutex.c
===
--- linux-
Linus Torvalds wrote:
So we do have special issues. And exactly _because_ we have special issues
we should also expect that some compiler defaults simply won't ever really
be appropriate for us.
That is, of course, true.
However, the Linux kernel (and quite a few other kernels) is a very
> So we do have special issues. And exactly _because_ we have special issues
> we should also expect that some compiler defaults simply won't ever really
> be appropriate for us.
I agree that the kernel needs quite different inlining heuristics
than let's say a template heavy C++ program. I gues
On Fri, 9 Jan 2009, Andi Kleen wrote:
>
> Universal noinline would also be a bad idea because of its
> costs (4.1% text size increase). Perhaps should make it
> a CONFIG option for debugging though.
That's _totally_ the wrong way.
If you can reproduce an issue on your machine, you generally do
On Fri, 9 Jan 2009, Matthew Wilcox wrote:
>
> That seems like valuable feedback to give to the GCC developers.
Well, one thing we should remember is that the kernel really _is_ special.
The kernel not only does things no other program tends to do (inline asms
are unusual in the first place -
> I think that's the point. gcc will not get it right.
I don't think that's necessary an universal truth. It
can be probably fixed.
> So we need to do it ourselves in the kernel sources.
> We may not like it, but it's the only way to guarantee reproducable
> reliable inline / noinline decisions
On Fri, 9 Jan 2009 18:47:19 +0100
Andi Kleen wrote:
> On Fri, Jan 09, 2009 at 10:28:01AM -0700, Matthew Wilcox wrote:
> > On Fri, Jan 09, 2009 at 06:20:11PM +0100, Andi Kleen wrote:
> > > Also cc Honza in case he has comments (you might want
> > > to review more of the thread in the archives)
>
On Thu, 8 Jan 2009, Peter Zijlstra wrote:
> > Well, at least we do unless you enable that broken paravirt support.
> > I'm not at all clear on why CONFIG_PARAVIRT wants to use inferior
> > locks, but I don't much care.
> Because the virtual cpu that has the ticket might not get scheduled for
> a
On Fri, Jan 09, 2009 at 06:47:19PM +0100, Andi Kleen wrote:
> On Fri, Jan 09, 2009 at 10:28:01AM -0700, Matthew Wilcox wrote:
> > On Fri, Jan 09, 2009 at 06:20:11PM +0100, Andi Kleen wrote:
> > > Also cc Honza in case he has comments (you might want
> > > to review more of the thread in the archive
On Fri, Jan 09, 2009 at 10:28:01AM -0700, Matthew Wilcox wrote:
> On Fri, Jan 09, 2009 at 06:20:11PM +0100, Andi Kleen wrote:
> > Also cc Honza in case he has comments (you might want
> > to review more of the thread in the archives)
>
> I think this particular bug is already known and discussed:
On Fri, Jan 09, 2009 at 09:11:47AM -0800, Linus Torvalds wrote:
> IIRC, the numbers mean different things for different versions of gcc, and
> I think using the parameters was very strongly discouraged by gcc
> developers. IOW, they were meant for gcc developers internal tuning
> efforts, not re
On Fri, Jan 09, 2009 at 06:20:11PM +0100, Andi Kleen wrote:
> Also cc Honza in case he has comments (you might want
> to review more of the thread in the archives)
I think this particular bug is already known and discussed:
http://gcc.gnu.org/ml/gcc/2008-12/msg00365.html
and it hints at being f
> I vote for the, get rid of the current inline, rename __always_inline to
There is some code that absolutely requires inline for correctness,
like the x86-64 vsyscall code. I would advocate to keep the
explicit __always_inline at least there to make it very clear.
> inline, and then remove all
On Fri, 9 Jan 2009, Steven Rostedt wrote:
>
> I vote for the, get rid of the current inline, rename __always_inline to
> inline, and then remove all non needed inlines from the kernel.
This is what we do all the time, and historically have always done.
But
- CONFIG_OPTIMIZE_INLINING=y screws
On Fri, Jan 09, 2009 at 09:03:12AM -0500, jim owens wrote:
> They also know inlining may increase program object size.
> That inlining will reduce object size on many architectures
> if the function is small is just a happy side effect to them.
The problem is that the threshold for that is archite
On Fri, 9 Jan 2009, Andi Kleen wrote:
>
> There's also one alternative: gcc's inlining algorithms are extensibly
> tunable with --param. We might be able to find a set of numbers that
> make it roughly work like we want it by default.
We tried that.
IIRC, the numbers mean different things for
On Fri, 9 Jan 2009, H. Peter Anvin wrote:
> Dirk Hohndel wrote:
> >
> > Does gcc actually follow the "promise"? If that's the case (and if it's
> > considered a bug when it doesn't), then we can get what Linus wants by
> > annotating EVERY function with either __always_inline or noinline.
> >
>
On Fri, Jan 09, 2009 at 08:46:20AM -0800, Dirk Hohndel wrote:
> On Fri, 09 Jan 2009 08:34:57 -0800
> "H. Peter Anvin" wrote:
> >
> > As far as naming is concerned, gcc effectively supports four levels,
> > which *currently* map onto macros as follows:
> >
> > __always_inline Inline u
Dirk Hohndel wrote:
>
> Does gcc actually follow the "promise"? If that's the case (and if it's
> considered a bug when it doesn't), then we can get what Linus wants by
> annotating EVERY function with either __always_inline or noinline.
>
__always_inline and noinline does work.
-hpa
-
On Fri, 9 Jan 2009 08:44:47 -0800 (PST)
Linus Torvalds wrote:
> On Fri, 9 Jan 2009, H. Peter Anvin wrote:
> > As far as naming is concerned, gcc effectively supports four levels,
> > which *currently* map onto macros as follows:
> >
> > __always_inline Inline unconditionally
> > inlin
On Fri, 09 Jan 2009 08:34:57 -0800
"H. Peter Anvin" wrote:
>
> As far as naming is concerned, gcc effectively supports four levels,
> which *currently* map onto macros as follows:
>
> __always_inline Inline unconditionally
> inlineInlining hint
>
On Fri, 9 Jan 2009, H. Peter Anvin wrote:
> As far as naming is concerned, gcc effectively supports four levels,
> which *currently* map onto macros as follows:
>
> __always_inline Inline unconditionally
> inlineInlining hint
> Standard heuristi
On Fri, 9 Jan 2009, Linus Torvalds wrote:
>
>
> On Fri, 9 Jan 2009, Steven Rostedt wrote:
> >
> > I was going to say a while ago...
> > In PREEMPT=y the need_resched() is not needed at all. If you have
> > preemption enabled, you will get preempted in that loop. No need for the
> > need_resc
Ingo Molnar wrote:
>
> My goal is to make the kernel smaller and faster, and as far as the
> placement of 'inline' keywords goes, i dont have too strong feelings about
> how it's achieved: they have a certain level of documentation value
> [signalling that a function is _intended_ to be lightwe
On Fri, 9 Jan 2009, H. Peter Anvin wrote:
>
> __asm_inline was my suggestion, to distinguish "inline this
> unconditionally because gcc screws up in the presence of asm()"
THERE IS NO ASM IN THERE!
Guys, look at the code. No asm. The whole notion that gcc gets confused by
inline asms IS BOGUS
1 - 100 of 118 matches
Mail list logo
