From owner-freebsd-hackers@freebsd.org Thu Aug 23 10:27:38 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 D8B1A1089194 for ; Thu, 23 Aug 2018 10:27:38 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (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 79E148C174 for ; Thu, 23 Aug 2018 10:27:37 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [62.141.128.70]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 2862C2600C9; Thu, 23 Aug 2018 12:27:36 +0200 (CEST) Subject: Re: epoch(9) background information? To: Sebastian Huber , Eugene Grosbein , FreeBSD References: <3bfedcc3-0dae-7979-2bd4-da83f2c67e87@embedded-brains.de> <5B7E7804.4030907@grosbein.net> <978ae736-89b9-6d83-e2a1-d2834ca8ae55@embedded-brains.de> From: Hans Petter Selasky Message-ID: <90e16238-6e4d-5d3d-499d-2a19a49be78c@selasky.org> Date: Thu, 23 Aug 2018 12:27:12 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: <978ae736-89b9-6d83-e2a1-d2834ca8ae55@embedded-brains.de> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit 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 10:27:39 -0000 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. --HPS