Re: [tip:core/locking] x86/smp: Move waiting on contended ticketlock out of line

From: Ingo Molnar
Date: Thu Feb 14 2013 - 05:50:39 EST



* Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:

> On Wed, Feb 13, 2013 at 8:20 AM, Linus Torvalds
> <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> >
> > Adding an external function call is *horrible*, and you
> > might almost as well just uninline the spinlock entirely if
> > you do this. It means that all the small callers now have
> > their registers trashed, whether the unlikely function call
> > is taken or not, and now leaf functions aren't leaves any
> > more.
>
> Btw, we've had things like this before, and I wonder if we
> could perhaps introduce the notion of a "light-weight call"
> for fastpath code that calls unlikely slow-path code..
>
> In particular, see the out-of-line code used by the rwlocks
> etc (see "arch_read_lock()" for an example in
> arch/x86/include/asm/spinlock.h and arch/x86/lib/rwlock.S),
> where we end up calling things from inline asm, with one big
> reason being exactly the fact that a "normal" C call has such
> horribly detrimental effects on the caller.
>
> Sadly, gcc doesn't seem to allow specifying which registers
> are clobbered any easy way, which means that both the caller
> and the callee *both* tend to need to have some asm interface.
> So we bothered to do this for __read_lock_failed, but we have
> *not* bothered to do the same for the otherwise very similar
> __mutex_fastpath_lock() case, for example.

At least on x86, how about saving *all* volatile registers in
the slow out of line code path (to stack)?

That means we wouldn't have to do anything fancy with the called
functions, and the caller would see minimal register impact. It
would also be reasonably robust and straightforward assembly
code.

It blows up the slow path somewhat, but it would allow us to
keep the fast-path register impact even smaller - as the slow
path would only have memory content side effects.

Am I missing something?

Thanks,

Ingo
--
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/