From owner-freebsd-current@freebsd.org Fri Dec 16 09:31:11 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 CCDB2C77108 for ; Fri, 16 Dec 2016 09:31:11 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from smtp.fagskolen.gjovik.no (smtp.fagskolen.gjovik.no [IPv6:2001:700:1100:1:200:ff:fe00:b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.fagskolen.gjovik.no", Issuer "Fagskolen i Gj??vik" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 6128E1308 for ; Fri, 16 Dec 2016 09:31:11 +0000 (UTC) (envelope-from trond@fagskolen.gjovik.no) Received: from mail.fig.ol.no (localhost [127.0.0.1]) by mail.fig.ol.no (8.15.2/8.15.2) with ESMTPS id uBG9V1Lk008546 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Fri, 16 Dec 2016 10:31:01 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) Received: from localhost (trond@localhost) by mail.fig.ol.no (8.15.2/8.15.2/Submit) with ESMTP id uBG9V1sr008543 for ; Fri, 16 Dec 2016 10:31:01 +0100 (CET) (envelope-from trond@fagskolen.gjovik.no) X-Authentication-Warning: mail.fig.ol.no: trond owned process doing -bs Date: Fri, 16 Dec 2016 10:31:01 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= Sender: Trond.Endrestol@fagskolen.gjovik.no To: FreeBSD current Subject: /usr/share/man/man4/cc.4.gz obsolete? Message-ID: User-Agent: Alpine 2.20 (BSF 67 2015-01-07) Organization: Fagskolen Innlandet OpenPGP: url=http://fig.ol.no/~trond/trond.key MIME-Version: 1.0 X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.1 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on mail.fig.ol.no Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.23 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 09:31:11 -0000 /usr/share/man/man4/cc.4.gz shows up as obsolete whenever I run make -C /usr/src check-old. make -C /usr/src delete-old removes the file, but make -C /usr/src installworld adds it. System is base/head r309889. Please make up your mind. -- +-------------------------------+------------------------------------+ | Vennlig hilsen, | Best regards, | | Trond Endrestøl, | Trond Endrestøl, | | IT-ansvarlig, | System administrator, | | Fagskolen Innlandet, | Gjøvik Technical College, Norway, | | tlf. mob. 952 62 567, | Cellular...: +47 952 62 567, | | sentralbord 61 14 54 00. | Switchboard: +47 61 14 54 00. | +-------------------------------+------------------------------------+ From owner-freebsd-current@freebsd.org Fri Dec 16 13:28:41 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 E3AA6C8337F for ; Fri, 16 Dec 2016 13:28:41 +0000 (UTC) (envelope-from slw@zxy.spb.ru) 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 D1CE1F67 for ; Fri, 16 Dec 2016 13:28:41 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: by mailman.ysv.freebsd.org (Postfix) id CE118C8337E; Fri, 16 Dec 2016 13:28:41 +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 CDBA7C8337D for ; Fri, 16 Dec 2016 13:28:41 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from zxy.spb.ru (zxy.spb.ru [195.70.199.98]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 91AC3F66 for ; Fri, 16 Dec 2016 13:28:41 +0000 (UTC) (envelope-from slw@zxy.spb.ru) Received: from slw by zxy.spb.ru with local (Exim 4.86 (FreeBSD)) (envelope-from ) id 1cHsYu-0005kF-QS; Fri, 16 Dec 2016 16:28:36 +0300 Date: Fri, 16 Dec 2016 16:28:36 +0300 From: Slawa Olhovchenkov To: Luigi Rizzo Cc: current@freebsd.org Subject: Re: best approximation of getcpu() ? Message-ID: <20161216132836.GB90401@zxy.spb.ru> References: <20161216021719.GA63374@onelab2.iet.unipi.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161216021719.GA63374@onelab2.iet.unipi.it> User-Agent: Mutt/1.5.24 (2015-08-30) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: slw@zxy.spb.ru X-SA-Exim-Scanned: No (on zxy.spb.ru); SAEximRunCond expanded to false 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 13:28:42 -0000 On Fri, Dec 16, 2016 at 03:17:19AM +0100, Luigi Rizzo 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 ? Most hard task is discover what irq handle specific NIC tx/rx queue (assume irq already have affinity). After this discover (by some magic shit) no problem to start pthread and execute some like CPU_ZERO(&mask); CPU_SET(i, &mask); pthread_attr_init(&attr); pthread_attr_setaffinity_np(&attr, sizeof(mask), &mask); pthread_create(&balancer[i].tid, &attr, balancer_thread, &balancer[i]); pthread_set_name_np(balancer[i].tid, name);