Date: Fri, 16 Dec 2016 03:17:19 +0100 From: Luigi Rizzo <rizzo@iet.unipi.it> To: current@freebsd.org Subject: best approximation of getcpu() ? Message-ID: <20161216021719.GA63374@onelab2.iet.unipi.it>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20161216021719.GA63374>