epoch(9) background information?

[Mark Johnston]

On Thu, Aug 23, 2018 at 12:27:12PM +0200, 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.

Threads in preemptible epoch sections are allowed to acquire locks, so
critical_enter()/exit() isn't a suitable replacement for epoch sections.
I think a fallback implementation could be written without CK for the
!SMP case, but it would require some work.