On Wed, Jan 21, 2009 at 10:54:18AM +0100, Andi Kleen wrote:
> > The point is that the compiler is then free to do it. If things
> > slow down after the compiler gets *more* information, then that
> > is a problem with the compiler heuristics rather than the
> > information we give it.
>
> The poin
> The point is that the compiler is then free to do it. If things
> slow down after the compiler gets *more* information, then that
> is a problem with the compiler heuristics rather than the
> information we give it.
The point was the -Os disables it typically then.
(not always, compiler heuristi
On Wed, Jan 21, 2009 at 10:20:49AM +0100, Andi Kleen wrote:
> On Wed, Jan 21, 2009 at 09:52:08AM +0100, Nick Piggin wrote:
> > On Wed, Jan 21, 2009 at 09:54:02AM +0100, Andi Kleen wrote:
> > > > GCC 4.3.2. Maybe i missed something obvious?
> > >
> > > The typical use case of restrict is to tell it
On Wed, Jan 21, 2009 at 09:52:08AM +0100, Nick Piggin wrote:
> On Wed, Jan 21, 2009 at 09:54:02AM +0100, Andi Kleen wrote:
> > > GCC 4.3.2. Maybe i missed something obvious?
> >
> > The typical use case of restrict is to tell it that multiple given
> > arrays are independent and then give the loop
On Wed, Jan 21, 2009 at 09:54:02AM +0100, Andi Kleen wrote:
> > GCC 4.3.2. Maybe i missed something obvious?
>
> The typical use case of restrict is to tell it that multiple given
> arrays are independent and then give the loop optimizer
> more freedom to handle expressions in the loop that
> acc
> GCC 4.3.2. Maybe i missed something obvious?
The typical use case of restrict is to tell it that multiple given
arrays are independent and then give the loop optimizer
more freedom to handle expressions in the loop that
accesses these arrays.
Since there are no loops in the list functions noth
Ingo Molnar wrote:
Hm, GCC uses __restrict__, right?
I'm wondering whether there's any internal tie-up between alias analysis
and the __restrict__ keyword - so if we turn off aliasing optimizations
the __restrict__ keyword's optimizations are turned off as well.
Actually I suspect that "r
* Linus Torvalds wrote:
> On Tue, 20 Jan 2009, Ingo Molnar wrote:
> >
> > (Different-type pointer uses are a common pattern: we have a lot of
> > places where we have pointers to structures with different types so
> > strict-aliasing optimization opportunities apply quite broadly
> > already
On Tue, 20 Jan 2009, Ingo Molnar wrote:
>
> (Different-type pointer uses are a common pattern: we have a lot of places
> where we have pointers to structures with different types so
> strict-aliasing optimization opportunities apply quite broadly already.)
Yes and no.
It's true that the kern
* David Woodhouse wrote:
> On Tue, 2009-01-20 at 13:38 +0100, Ingo Molnar wrote:
> >
> > * Nick Piggin wrote:
> >
> > > > > it seems like a nice opt-in thing that can be used where the aliases
> > > > > are verified and the code is particularly performance critical...
> > > >
> > > > Yes. I
On Tue, 2009-01-20 at 13:38 +0100, Ingo Molnar wrote:
>
> * Nick Piggin wrote:
>
> > > > it seems like a nice opt-in thing that can be used where the aliases
> > > > are verified and the code is particularly performance critical...
> > >
> > > Yes. I think we could use it in the kernel, althou
On Mon, Jan 19, 2009 at 9:01 PM, Linus Torvalds
wrote:
>
>
> On Mon, 19 Jan 2009, Nick Piggin wrote:
>>
>> I want to know what is the problem with the restrict keyword?
>> I'm sure I've read Linus ranting about how bad it is in the
>> past...
>
> No, I don't think I've ranted about 'restrict'. I t
* Nick Piggin wrote:
> > > it seems like a nice opt-in thing that can be used where the aliases
> > > are verified and the code is particularly performance critical...
> >
> > Yes. I think we could use it in the kernel, although I'm not sure how
> > many cases we would ever find where we real
> The problem with 'restrict' is that almost nobody uses it, and it does
Also gcc traditionally didn't do a very good job using it (this
might be better in the very latest versions). At least some of the 3.x
often discarded this information.
> automatically. But it should work well as a way to
On Tue, Jan 20, 2009 at 08:01:52AM +1100, Linus Torvalds wrote:
>
>
> On Mon, 19 Jan 2009, Nick Piggin wrote:
> >
> > I want to know what is the problem with the restrict keyword?
> > I'm sure I've read Linus ranting about how bad it is in the
> > past...
>
> No, I don't think I've ranted about
On Mon, 19 Jan 2009, Nick Piggin wrote:
>
> I want to know what is the problem with the restrict keyword?
> I'm sure I've read Linus ranting about how bad it is in the
> past...
No, I don't think I've ranted about 'restrict'. I think it's a reasonable
solution for performance-critical code, an
On Mon, Jan 19, 2009 at 01:13:45AM +0100, Ingo Molnar wrote:
>
> * Bernd Schmidt wrote:
>
> > Linus Torvalds wrote:
> > > But you'll need some background to it:
> >
> > You paint a somewhat one-sided picture bordering on FUD.
>
> Type based aliasing should at most have been an opt-in for code
* Bernd Schmidt wrote:
> Linus Torvalds wrote:
> > But you'll need some background to it:
>
> You paint a somewhat one-sided picture bordering on FUD.
>
> > Type-based aliasing is _stupid_.
>
> Type-based aliasing is simply an application of the language definition,
> and depending on the co
On Mon, 12 Jan 2009, Linus Torvalds wrote:
> code tends to get a lot more I$ and D$ misses. Deep call-chains _will_
I feel like an idiot that I never realized that "I$" meant
"instruction cache" until now :-p
-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-b
On Mon, 12 Jan 2009, Bernd Schmidt wrote:
>
> Too lazy to construct one myself, I googled for examples, and here's a
> trivial one that shows how it affects the ability of the compiler to
> eliminate memory references:
Do you really think this is realistic or even relevant?
The fact is
(a)
On Mon, 12 Jan 2009, Jamie Lokier wrote:
>
> Sometimes code motion makes code faster and/or smaller but use more
> stack space. If you want to keep the stack use down, it blocks some
> other optimisations.
Uhh. Yes. Compiling is an exercise in trade-offs.
That doesn't mean that you should try
Linus Torvalds wrote:
> But you'll need some background to it:
You paint a somewhat one-sided picture bordering on FUD.
> Type-based aliasing is _stupid_.
Type-based aliasing is simply an application of the language definition,
and depending on the compiled application and/or target architecture
Linus Torvalds wrote:
> > This is about storage allocation, not aliases. Storage allocation only
> > depends on lifetime.
>
> Well, the thing is, code motion does extend life-times, and if you think
> you can move stores across each other (even when you can see that they
> alias statically) due
On Mon, 12 Jan 2009, Bernd Schmidt wrote:
>
> However, if the compiler chooses to put them into the same stack
> location, the RTL-based alias analysis will happily conclude (based on
> the differing types) that the reads from A and the writes to B can't
> possibly conflict, and some passes m
On Mon, 12 Jan 2009, Linus Torvalds wrote:
>
> Type-based aliasing is unacceptably stupid to begin with, and gcc took
> that stupidity to totally new heights by making it actually more important
> than even statically visible aliasing.
Btw, there are good forms of type-based aliasing.
The 'r
Linus Torvalds wrote:
>
> On Mon, 12 Jan 2009, Bernd Schmidt wrote:
>> Something at the back of my mind said "aliasing".
>>
>> $ gcc linus.c -O2 -S ; grep subl linus.s
>> subl$1624, %esp
>> $ gcc linus.c -O2 -S -fno-strict-aliasing; grep subl linus.s
>> subl$824, %esp
>>
>>
On Mon, 12 Jan 2009, H. Peter Anvin wrote:
>
> This is about storage allocation, not aliases. Storage allocation only
> depends on lifetime.
Well, the thing is, code motion does extend life-times, and if you think
you can move stores across each other (even when you can see that they
alias s
On Mon, 12 Jan 2009, Andi Kleen wrote:
>
> What I find nonsensical is that -fno-strict-aliasing generates
> better code here. Normally one would expect the compiler seeing
> more aliases with that option and then be more conservative
> regarding any sharing. But it seems to be the other way round
Andi Kleen wrote:
On Mon, Jan 12, 2009 at 11:02:17AM -0800, Linus Torvalds wrote:
Something at the back of my mind said "aliasing".
$ gcc linus.c -O2 -S ; grep subl linus.s
subl$1624, %esp
$ gcc linus.c -O2 -S -fno-strict-aliasing; grep subl linus.s
subl$824, %esp
That'
On Mon, Jan 12, 2009 at 11:02:17AM -0800, Linus Torvalds wrote:
> > Something at the back of my mind said "aliasing".
> >
> > $ gcc linus.c -O2 -S ; grep subl linus.s
> > subl$1624, %esp
> > $ gcc linus.c -O2 -S -fno-strict-aliasing; grep subl linus.s
> > subl$824, %esp
> >
On Mon, 12 Jan 2009, Bernd Schmidt wrote:
>
> Something at the back of my mind said "aliasing".
>
> $ gcc linus.c -O2 -S ; grep subl linus.s
> subl$1624, %esp
> $ gcc linus.c -O2 -S -fno-strict-aliasing; grep subl linus.s
> subl$824, %esp
>
> That's with 4.3.2.
Interes
Andi Kleen wrote:
> On Sun, Jan 11, 2009 at 04:21:03PM -0800, Linus Torvalds wrote:
>>
>> On Mon, 12 Jan 2009, Andi Kleen wrote:
>>> so at least least for this case it works. Your case also doesn't work
>>> for me. So it looks like gcc didn't like something you did in your test
>>> program.
>> I
* Jamie Lokier wrote:
> Ingo Molnar wrote:
> > If it's used once in a single .c file it should be inlined even if
> > it's large.
>
> As Linus has pointed out, because of GCC not sharing stack among
> different inlined functions, the above is surprisingly not true.
Yes, but note that this has
On Sun, 11 Jan 2009 11:26:41 pm David Woodhouse wrote:
> Sometimes you weren't going to get a backtrace if something goes wrong
> _anyway_.
Case in point - we've been struggling with some of our SuperMicro based
systems with AMD Barcelona B3 k10h CPUs *turning themselves off* when running
vario
Ingo Molnar wrote:
> If it's used once in a single .c file it should be inlined even if
> it's large.
As Linus has pointed out, because of GCC not sharing stack among
different inlined functions, the above is surprisingly not true.
In kernel it's a problem due to raw stack usage.
In userspace ap
Andi Kleen wrote:
>
> Weird. I wonder where this strange restriction comes from. It indeed
> makes this much less useful than it could be :/
>
Most likely they're collapsing at too early of a stage.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't
On Sun, Jan 11, 2009 at 04:21:03PM -0800, Linus Torvalds wrote:
>
>
> On Mon, 12 Jan 2009, Andi Kleen wrote:
> >
> > so at least least for this case it works. Your case also doesn't work
> > for me. So it looks like gcc didn't like something you did in your test
> > program.
>
> I very intent
On Mon, 12 Jan 2009, Andi Kleen wrote:
>
> so at least least for this case it works. Your case also doesn't work
> for me. So it looks like gcc didn't like something you did in your test
> program.
I very intentionally used _different_ types.
If you use the same type, gcc will apparenrly hap
On Sun, Jan 11, 2009 at 03:05:53PM -0800, Linus Torvalds wrote:
>
>
> On Sun, 11 Jan 2009, Linus Torvalds wrote:
> > On Sun, 11 Jan 2009, Andi Kleen wrote:
> > >
> > > Was -- i think that got fixed in gcc. But again only in newer versions.
> >
> > I doubt it. People have said that about a milli
On Sun, 11 Jan 2009, Linus Torvalds wrote:
> On Sun, 11 Jan 2009, Andi Kleen wrote:
> >
> > Was -- i think that got fixed in gcc. But again only in newer versions.
>
> I doubt it. People have said that about a million times, it has never
> gotten fixed, and I've never seen any actual proof.
I
On Sun, 11 Jan 2009, Andi Kleen wrote:
>
> Was -- i think that got fixed in gcc. But again only in newer versions.
I doubt it. People have said that about a million times, it has never
gotten fixed, and I've never seen any actual proof.
I think that what got fixed was that gcc now at least re
> Isn't the ioctl switch stack issue a separate GCC bug?
>
> It was/is assigning assigning separate space for local variables which
Was -- i think that got fixed in gcc. But again only in newer versions.
> are mutually exclusive. So instead of the stack footprint of the
> function with the switc
On Sun, 2009-01-11 at 21:14 +0100, Andi Kleen wrote:
>
> On the other hand (my personal opinion, not shared by everyone) is
> that the ioctl switch stack issue is mostly only a problem with 4K
> stacks and in the rare cases when I still run 32bit kernels
> I never set that option because I consi
On Sun, Jan 11, 2009 at 11:25:32AM -0800, Linus Torvalds wrote:
>
>
> On Sun, 11 Jan 2009, Andi Kleen wrote:
> >
> > The proposal was to use -fno-inline-functions-called-once (but
> > the resulting numbers were not promising)
>
> Well, the _optimal_ situation would be to not need it, because g
On Sun, 11 Jan 2009, Andi Kleen wrote:
>
> The proposal was to use -fno-inline-functions-called-once (but
> the resulting numbers were not promising)
Well, the _optimal_ situation would be to not need it, because gcc does a
good job without it. That implies trying to find a better balance bet
On Sun, Jan 11, 2009 at 12:26:41PM +, David Woodhouse wrote:
> - Unconditionally have 'inline' meaning 'always_inline'. If we say it,
> we should mean it.
>
> - Resist the temptation to use -fno-inline-functions. Allow GCC to
> inline other things if it wants to.
The proposal was
On Sat, 2009-01-10 at 04:02 +0100, Andi Kleen wrote:
> Long term that problem will hopefully disappear, as gcc learns to do cross
> source file inlining (like a lot of other compilers already do)
We've already been able to get GCC doing this for the kernel, in fact
(the --combine -fwhole-program s
* Linus Torvalds wrote:
> 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
> > i
Linus Torvalds wrote:
Actually, the real spin locks are now fair. We use ticket locks on x86.
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.
No, it will continue to use ti
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
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
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_.
> 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 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
* 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
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, 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, 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
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, 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
* 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
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
* 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, 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-
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, 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
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
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_resched() in the outer loop. Although I'm not sure how it would
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 % BITS_PER_L
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 % BITS_PER_LONG)) &
> (((unsi
On Fri, 2009-01-09 at 10:59 -0500, Steven Rostedt wrote:
> >
> > Adding that blocking on !owner utterly destroys everything.
>
> I was going to warn you about that ;-)
>
> Without the check for !owner, you are almost guaranteed to go to sleep
> every time. Here's why:
>
> You are spinning and
On Fri, 9 Jan 2009, Peter Zijlstra wrote:
> On Fri, 2009-01-09 at 11:47 +0100, Peter Zijlstra wrote:
>
> > > So I think the bug is still there, we just hid it better by breaking out
> > > of the loop with that "if (need_resched())" always eventually triggering.
> > > And it would be ok if it r
On Fri, 2009-01-09 at 16:06 +0100, Peter Zijlstra wrote:
> On Fri, 2009-01-09 at 11:47 +0100, Peter Zijlstra wrote:
>
> > > So I think the bug is still there, we just hid it better by breaking out
> > > of the loop with that "if (need_resched())" always eventually triggering.
> > > And it would
On Fri, 2009-01-09 at 11:47 +0100, Peter Zijlstra wrote:
> > So I think the bug is still there, we just hid it better by breaking out
> > of the loop with that "if (need_resched())" always eventually triggering.
> > And it would be ok if it really is guaranteed to _eventually_ trigger, and
> >
* H. Peter Anvin wrote:
> Andi Kleen wrote:
> >> I'll try to annotate the inline asms (there's not _that_ many of them),
> >> and measure what the size impact is.
> >
> > You can just use the patch I submitted and that you rejected for
> > most of them :)
>
> I just ran a sample build for x86
On Fri, 2009-01-09 at 04:35 +0100, Andi Kleen wrote:
> On Thu, Jan 08, 2009 at 05:44:25PM -0800, H. Peter Anvin wrote:
> > Harvey Harrison wrote:
> > >>
> > >> We might still try the second or third options, as i think we shouldnt
> > >> go
> > >> back into the business of managing the inline att
On Thu, 2009-01-08 at 11:54 -0800, Linus Torvalds wrote:
> I was pretty sure that adding the unlocked loop should provably not change
> the mutex lock semantics. Why? Because it's just basically equivalent to
> just doing the mutex_trylock() without really changing anything really
> fundamental
On Thu, 2009-01-08 at 11:13 -0800, Linus Torvalds wrote:
>
> On Thu, 8 Jan 2009, Chris Mason wrote:
> >
> > It is less fair though, the 50 proc parallel creates had a much bigger
> > span between the first and last proc's exit time. This isn't a huge
> > shock, I think it shows the hot path is c
> foo()
> {
> char a[1000];
> }
>
> bar()
> {
> char a[1000];
> }
>
> zot()
> {
> foo();
> bar();
> }
>
> uses 2000 bytes of stack.
> And with the right compiler version.
I believe that's fixed in newer gcc versions.
For old gccs we might indeed need to add noinlines th
On Thu, Jan 08, 2009 at 07:42:48PM -0800, Linus Torvalds wrote:
> > I actually often use noinline when developing code simply because it
> > makes it easier to read oopses when gcc doesn't inline ever static
> > (which it normally does if it only has a single caller)
>
> Yes. Gcc inlining is a to
On Fri, 9 Jan 2009 04:35:31 +0100 Andi Kleen wrote:
> On Thu, Jan 08, 2009 at 05:44:25PM -0800, H. Peter Anvin wrote:
> > Harvey Harrison wrote:
> > >>
> > >> We might still try the second or third options, as i think we shouldnt
> > >> go
> > >> back into the business of managing the inline at
1 - 100 of 136 matches
Mail list logo
