Date: Thu, 15 Dec 2016 20:10:06 -0700 From: Alan Somers <asomers@freebsd.org> To: Luigi Rizzo <rizzo@iet.unipi.it> Cc: "current@freebsd.org" <current@freebsd.org> Subject: Re: best approximation of getcpu() ? Message-ID: <CAOtMX2hdkCk3ho%2Byedpv7iPPi97be4eFViYm4%2Bmi8EC-iR2Uvg@mail.gmail.com> In-Reply-To: <20161216021719.GA63374@onelab2.iet.unipi.it> References: <20161216021719.GA63374@onelab2.iet.unipi.it>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Dec 15, 2016 at 7:17 PM, Luigi Rizzo <rizzo@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2hdkCk3ho%2Byedpv7iPPi97be4eFViYm4%2Bmi8EC-iR2Uvg>