Date: Fri, 16 Dec 2016 10:31:01 +0100 (CET) From: =?ISO-8859-1?Q?Trond_Endrest=F8l?= <Trond.Endrestol@fagskolen.gjovik.no> To: FreeBSD current <freebsd-current@freebsd.org> Subject: /usr/share/man/man4/cc.4.gz obsolete? Message-ID: <alpine.BSF.2.20.1612161028130.59684@mail.fig.ol.no>
next in thread | raw e-mail | index | archive | help
/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: <owner-freebsd-current@freebsd.org> 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 <freebsd-current@mailman.ysv.freebsd.org>; 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 <freebsd-current@freebsd.org>; 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 <current@mailman.ysv.freebsd.org>; 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 <current@freebsd.org>; 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 <slw@zxy.spb.ru>) id 1cHsYu-0005kF-QS; Fri, 16 Dec 2016 16:28:36 +0300 Date: Fri, 16 Dec 2016 16:28:36 +0300 From: Slawa Olhovchenkov <slw@zxy.spb.ru> To: Luigi Rizzo <rizzo@iet.unipi.it> 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: <locally generated> 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 <freebsd-current.freebsd.org> List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>; List-Post: <mailto:freebsd-current@freebsd.org> List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help> List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-current>, <mailto:freebsd-current-request@freebsd.org?subject=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);
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?alpine.BSF.2.20.1612161028130.59684>