best approximation of getcpu() ?

[Alan Somers]

On Thu, Dec 15, 2016 at 7:17 PM, Luigi Rizzo <rizzo at iet.unipi.it> wrote:
> TL;DR; is there any way a userspace thread in FreeBSD can tell
> on which CPU it is (was) running ? I know the thread can migrate
> at any time but as long as the event is rare I can live with
> the occasionally wrong information.
> Linux has getcpu(2) which is exposed by glibc as sched_getcpu(3),
> but the linuxulator in FreeBSD only has a dummy (uniplemented)
> function for that syscall.
>
> FULL DESCRIPTION
> It is common practice, when building scalable systems, to use per-cpu
> resources that can be accessed without contention by just protecting
> them with a CLI; STI; pair. Multiqueue NICs typically do this to
> build a lock-free transmit path. In [1] we show an in-kernel
> scheduler that maps a large number of clients to a (much smaller)
> number of lock-free mailboxes, one per core.
>
> In the kernel we can do CLI and STI and access curcpu.
> In userspace a suitably privileged process can indeed open /dev/io
> to acquire the right to use CLI and STI, though I am not sure
> wether curcpu is available in some way.
>
> Of course running userspace code with interrupts disabled is risky,
> but we can use the per-cpu trick with a small tweak, namely,
> protect each resouce with a lock. If the thread does not migrate
> imediately after getcpu(), we will access the lock (and the resource)
> almost always from the same cpu hence very efficiently.
> Occasional migration may cause contention but should not
> alter too much the good performance of this scheme.
>
> So, any idea before I add a syscall/ioctl (or extend one)
> to export this information ?
>
>         thanks
>         luigi
>
>
> [1] http://info.iet.unipi.it/~luigi/papers/20160921-pspat.pdf

What about pthread_setaffinity(3) and friends?  You can use it to pin
a thread to a single CPU, and know that it will never migrate.

-Alan