Re: [2.6 patch] kernel/sched*: optimize inlining

[Sam Ravnborg]

> 
> But we are in an area where "common sense" doesn't help if we rely on 
> some specific behaviour.
> 
> > > gcc 4.3 even ignores the unlikely() hint in timespec_add_ns()
> > > (we now have a workaround for this in the kernel).
> > I do not follow the logic here.
> > Gcc may fail in a few cases to do what we expect but that
> > is far from that we shall assume that it always fails.
> 
> My logic is simple:
> 
> If you rely on a hint that assumption can break.

And the fix is to remove all hints?
No - the fix is to replace hints with forced rules so we do
_not_ rely on hint when we need to know what shall happen.

By your definition we should replace all instances
of __always_inline with inline and define both to
__attribute__((always_inline)). Because inline
should be an order not a hint.

And all I try to understand is why you see no value in the
distinction on the possibility to annotate a function:

a)
   static void inline foo() { ... }

and

b)
   static void __attribute__((always_inline)) foo() { ... }

But you continue to pretend that a hint is useless because we
are not sure what happens so we are equally well suited with
no hint at all.
Even so your patch showed that gcc (at least my ancient 4.1.1)
took notice of the inline hint and in some cases did what
it was hinted to do.

On the gcc < 4.0 an its ability to inline properly...
It has been accepted on this list for a long time that
gcc < 4.0 is bad at inlining.
This may be wrong or it may be rigth - I dunno.
But when sending in a patch that suddenly breaks with this
assumption then it should at least be followed with some
kind of information why it does not fail with gcc < 4.0.
And please stop pushing it back to others because this
is stuff that should be in the initial patch submission.

...

> Provocation is the only way of communication that works on this list.

So this was pure time waste. Thanks!
Please do not waste my time answering this.

	Sam
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/