Date: Thu, 23 Aug 2018 12:59:58 +0200 From: Sebastian Huber <sebastian.huber@embedded-brains.de> To: Hans Petter Selasky <hps@selasky.org>, Eugene Grosbein <eugen@grosbein.net>, FreeBSD <freebsd-hackers@freebsd.org> Subject: Re: epoch(9) background information? Message-ID: <68c80dd6-a811-06c1-27d9-25e99e9fd4ed@embedded-brains.de> In-Reply-To: <90e16238-6e4d-5d3d-499d-2a19a49be78c@selasky.org> References: <db397431-2c4c-64de-634a-20f38ce6a60e@embedded-brains.de> <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>
next in thread | previous in thread | raw e-mail | index | archive | help
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= .
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?68c80dd6-a811-06c1-27d9-25e99e9fd4ed>