Re: [RFC PATCH 1/2] thread_local_abi system call: caching current CPU number (x86)

From	Andy Lutomirski <luto@amacapital.net>
Newsgroups	linux.kernel
Subject	Re: [RFC PATCH 1/2] thread_local_abi system call: caching current CPU number (x86)
Date	2015-12-13 21:30 +0100
Message-ID	<qFlrk-4EA-9@gated-at.bofh.it> (permalink)
References	<qEbDI-87n-3@gated-at.bofh.it> <qFjpw-3nE-13@gated-at.bofh.it> <qFkYi-4eF-5@gated-at.bofh.it> <qFlhD-4AO-3@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

On Sun, Dec 13, 2015 at 12:18 PM, Andi Kleen <andi@firstfloor.org> wrote:
>> In the context of restartable sequences [1] [2], the goal is to turn
>> atomic operations on per-cpu data into a sequence of simple load/store
>> operations. Therefore, improving getcpu from 12ns to 0.3ns will have a
>
> I don't think LSL is 12ns. It's a few cycles.

11ns on my Skylale laptop.  (rdtscp is now almost as fast as lsl.)
FWIW, a failed LSL is 55ns.

We could play sneaky tricks and use SGDT instead.  Long term on x86, I
think we should be using per-cpu segments, though.

>
>> Moreover, AFAIU, restartable sequences cannot do the function call
>> required by the  vdso while within the c.s.: those need to entirely fit
>> within an inline assembly. So this CPU number caching actually enables
>> restartable sequences, whereas the vdso approach cannot be used in that
>> context.
>
> You can use the LSL directly though. In practice people already rely
> on it (and it's very cheap on the kernel side), so it's a defacto ABI
> and could be documented.
>
> So it's not function call vs load, but LSL vs load.

I do wonder if the function call itself is cheap enough that we should
do this entirely within the vDSO.  Unfortunately, the vDSO can't use
TLS, so that's not so easy without trickery.

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

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [RFC PATCH 1/2] thread_local_abi system call: caching current  CPU number (x86) Andi Kleen <andi@firstfloor.org> - 2015-12-13 19:20 +0100
  Re: [RFC PATCH 1/2] thread_local_abi system call: caching current  CPU number (x86) Mathieu Desnoyers <mathieu.desnoyers@efficios.com> - 2015-12-13 21:00 +0100
    Re: [RFC PATCH 1/2] thread_local_abi system call: caching current  CPU number (x86) Andi Kleen <andi@firstfloor.org> - 2015-12-13 21:20 +0100
      Re: [RFC PATCH 1/2] thread_local_abi system call: caching current CPU  number (x86) Andy Lutomirski <luto@amacapital.net> - 2015-12-13 21:30 +0100

csiph-web