epoch(9) background information?

[Ian Lepore]

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