From owner-freebsd-current@freebsd.org Fri Dec 16 02:11:55 2016 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E9632C77473 for ; Fri, 16 Dec 2016 02:11:55 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DB4D81D3B for ; Fri, 16 Dec 2016 02:11:55 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by mailman.ysv.freebsd.org (Postfix) id DA63EC77472; Fri, 16 Dec 2016 02:11:55 +0000 (UTC) Delivered-To: current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DA0ACC77471 for ; Fri, 16 Dec 2016 02:11:55 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: from onelab2.iet.unipi.it (onelab2.iet.unipi.it [131.114.59.238]) by mx1.freebsd.org (Postfix) with ESMTP id A80951D39 for ; Fri, 16 Dec 2016 02:11:55 +0000 (UTC) (envelope-from luigi@onelab2.iet.unipi.it) Received: by onelab2.iet.unipi.it (Postfix, from userid 275) id EC7837300A; Fri, 16 Dec 2016 03:17:19 +0100 (CET) Date: Fri, 16 Dec 2016 03:17:19 +0100 From: Luigi Rizzo To: current@freebsd.org Subject: best approximation of getcpu() ? Message-ID: <20161216021719.GA63374@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.20 (2009-06-14) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Dec 2016 02:11:56 -0000 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