From owner-freebsd-hackers@freebsd.org Thu Aug 23 11:00:05 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 0C10F108A018 for ; Thu, 23 Aug 2018 11:00:05 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) (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 8134C8D357 for ; Thu, 23 Aug 2018 11:00:04 +0000 (UTC) (envelope-from sebastian.huber@embedded-brains.de) Received: from [78.46.172.3] (helo=sslproxy06.your-server.de) by dedi548.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.85_2) (envelope-from ) id 1fsnLM-0007jA-ID; Thu, 23 Aug 2018 13:00:00 +0200 Received: from [82.135.62.35] (helo=mail.embedded-brains.de) by sslproxy06.your-server.de with esmtpsa (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1fsnLM-000BVB-Av; Thu, 23 Aug 2018 13:00:00 +0200 Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 4F3392A165C; Thu, 23 Aug 2018 13:00:03 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id W_VM5HCn3E8f; Thu, 23 Aug 2018 13:00:02 +0200 (CEST) Received: from localhost (localhost.localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id DBC312A167F; Thu, 23 Aug 2018 13:00:02 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id VqEnMbN2cYnY; Thu, 23 Aug 2018 13:00:02 +0200 (CEST) Received: from [192.168.96.149] (unknown [192.168.96.149]) by mail.embedded-brains.de (Postfix) with ESMTPSA id B24C42A165C; Thu, 23 Aug 2018 13:00:02 +0200 (CEST) Subject: Re: epoch(9) background information? To: Hans Petter Selasky , Eugene Grosbein , FreeBSD 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> From: Sebastian Huber Message-ID: <68c80dd6-a811-06c1-27d9-25e99e9fd4ed@embedded-brains.de> Date: Thu, 23 Aug 2018 12:59:58 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <90e16238-6e4d-5d3d-499d-2a19a49be78c@selasky.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-GB Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldinet.de X-Virus-Scanned: Clear (ClamAV 0.100.1/24865/Thu Aug 23 07:52:53 2018) 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 11:00:05 -0000 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 lea= st >>>> from my point of view). However, FreeBSD has still the SMP=20 >>>> 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 a= n >>>> exotic environment which will get less and less well supported in th= e >>>> future? I just need some guidance so that I can better plan for futu= re >>>> FreeBSD baseline updates. >>> FreeBSD as virtualized uniprocessor guest should be supported at=20 >>> full scale, >>> as well as embedded applications using single core x86 and non-x86=20 >>> CPUs. >> >> If something should be supported, then there must be also someone who=20 >> ensures that this is actually the case. I don't know the FreeBSD=20 >> community good enough to judge if there is sufficient=20 >> manpower/funding/interest for a well supported uni-processor FreeBSD.=20 >> =C2=A0From the commits it is clear that FreeBSD receives a lot of=20 >> attention from CDN providers such as Netflix and Limelight Networks.=20 >> They probably don't care about uni-processor system support at all.=20 >> The use of lock-free data structures (Concurrency Kit) and the epoch=20 >> memory reclamation are now a mandatory infrastructure. There is no=20 >> FreeBSD configuration option to avoid this. >> >> The Concurrency Kit in sys/contrib/ck has no explicit support for the=20 >> FreeBSD RISC-V and MIPS architectures. So, I guess the fall-back=20 >> sys/contrib/ck/include/gcc/ck_pr.h is used. The atomic support in=20 >> sys/contrib/ck partially duplicates/extends the general atomic=20 >> support of the FreeBSD kernel ATOMIC(9). To me it is a bit unclear=20 >> what will be the future direction in the FreeBSD kernel with respect=20 >> to lock-free data structures. >> > > Hi Sebastian, > > Do you have something like critical_enter() to disable pre-emption in=20 > your OS? If you don't need to support SMP, the CPU pinning in the=20 > EPOCH can be replaced by a critial_enter() / critial_exit() pair. Yes, RTEMS has a critical_enter() to disable pre-emption (you could also=20 disable interrupts as a brute force means). You still have the lock-free data structure inside the critical section.=20 Currently, this is only ck_queue, so not a real problem. However, in=20 case some more advanced lock-less algorithms would appear with a bit of=20 spinning here and there, then this would need further adoptions for the=20 uni-processor system. Not all targets support C11 atomics in hardware,=20 some need libatomic (a GCC thing). --=20 Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.huber@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne des EHUG= .