From owner-freebsd-hackers@freebsd.org Thu Aug 23 12:58:24 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 447DF108D241 for ; Thu, 23 Aug 2018 12:58:24 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1b.ore.mailhop.org (outbound1b.ore.mailhop.org [54.200.247.200]) (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 C2A717113F for ; Thu, 23 Aug 2018 12:58:23 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 34e82e90-a6d4-11e8-93fa-f3ebd9db2b94 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.ore.mailhop.org (Halon) with ESMTPSA id 34e82e90-a6d4-11e8-93fa-f3ebd9db2b94; Thu, 23 Aug 2018 12:58:21 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w7NCwHg3097758; Thu, 23 Aug 2018 06:58:17 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1535029097.27158.180.camel@freebsd.org> Subject: Re: epoch(9) background information? From: Ian Lepore To: Sebastian Huber , Hans Petter Selasky , Eugene Grosbein , FreeBSD Date: Thu, 23 Aug 2018 06:58:17 -0600 In-Reply-To: <68c80dd6-a811-06c1-27d9-25e99e9fd4ed@embedded-brains.de> References: <3bfedcc3-0dae-7979-2bd4-da83f2c67e87@embedded-brains.de> <5B7E7804.4030907@grosbein.net> <978ae736-89b9-6d83-e2a1-d2834ca8ae55@embedded-brains.de> <90e16238-6e4d-5d3d-499d-2a19a49be78c@selasky.org> <68c80dd6-a811-06c1-27d9-25e99e9fd4ed@embedded-brains.de> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Aug 2018 12:58:24 -0000 On Thu, 2018-08-23 at 12:59 +0200, Sebastian Huber wrote: > On 23/08/18 12:27, Hans Petter Selasky wrote: > > > > On 8/23/18 11:28 AM, Sebastian Huber wrote: > > > > > > On 23/08/18 11:01, Eugene Grosbein wrote: > > > > > > > > On 23.08.2018 15:39, Sebastian Huber wrote: > > > > > > > > > > > > > > We used the FreeBSD network stack also on low-end targets > > > > > (uni-processor) such as MCF548x ColdFire, Atmel SAM V71, SPARC LEON, > > > > > etc. in current production environments (not legacy systems). The > > > > > introduction of lock-free data structures (Concurrency Kit) and this > > > > > epoch memory reclamation makes little sense on these targets (at least > > > > > from my point of view). However, FreeBSD has still the SMP  > > > > > configuration > > > > > option (sys/conf/options) which suggests that SMP is optional. Is a > > > > > uni-processor system something which is considered by the FreeBSD > > > > > community as a thing worth supporting or can I expect that this is an > > > > > exotic environment which will get less and less well supported in the > > > > > future? I just need some guidance so that I can better plan for future > > > > > FreeBSD baseline updates. > > > > FreeBSD as virtualized uniprocessor guest should be supported at  > > > > full scale, > > > > as well as embedded applications using single core x86 and non-x86  > > > > CPUs. > > > If something should be supported, then there must be also someone who  > > > ensures that this is actually the case. I don't know the FreeBSD  > > > community good enough to judge if there is sufficient  > > > manpower/funding/interest for a well supported uni-processor FreeBSD.  > > >  From the commits it is clear that FreeBSD receives a lot of  > > > attention from CDN providers such as Netflix and Limelight Networks.  > > > They probably don't care about uni-processor system support at all.  > > > The use of lock-free data structures (Concurrency Kit) and the epoch  > > > memory reclamation are now a mandatory infrastructure. There is no  > > > FreeBSD configuration option to avoid this. > > > > > > The Concurrency Kit in sys/contrib/ck has no explicit support for the  > > > FreeBSD RISC-V and MIPS architectures. So, I guess the fall-back  > > > sys/contrib/ck/include/gcc/ck_pr.h is used. The atomic support in  > > > sys/contrib/ck partially duplicates/extends the general atomic  > > > support of the FreeBSD kernel ATOMIC(9). To me it is a bit unclear  > > > what will be the future direction in the FreeBSD kernel with respect  > > > to lock-free data structures. > > > > > Hi Sebastian, > > > > Do you have something like critical_enter() to disable pre-emption in  > > your OS? If you don't need to support SMP, the CPU pinning in the  > > EPOCH can be replaced by a critial_enter() / critial_exit() pair. > Yes, RTEMS has a critical_enter() to disable pre-emption (you could also  > disable interrupts as a brute force means). > > You still have the lock-free data structure inside the critical section.  > Currently, this is only ck_queue, so not a real problem. However, in  > case some more advanced lock-less algorithms would appear with a bit of  > spinning here and there, then this would need further adoptions for the  > uni-processor system. Not all targets support C11 atomics in hardware,  > some need libatomic (a GCC thing). > Freebsd runs on many single-processor systems on all supported architectures and that isn't going to change. -- Ian