epoch(9) background information?

[Sebastian Huber]

On 21/08/18 15:38, Jacques Fourie wrote:
>
>
> On Tue, Aug 21, 2018 at 8:33 AM, Sebastian Huber 
> <sebastian.huber at embedded-brains.de 
> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>
>     Hello,
>
>     I update currently a port of the FreeBSD network stack, etc. to
>     the real-time operating system RTEMS from the head version at
>     2017-04-04 to the head version of today. I noticed that some
>     read-write locks are replaced by a relatively new stuff called
>     EPOCH(9). Is there some background information available for this?
>     The man page is a bit vague and searching for something named
>     epoch on the internet is not really great. For example, what is
>     the motivation for this change? How is this related to
>     read-copy-update (RCU)?
>
>     -- 
>     Sebastian Huber, embedded brains GmbH
>
>     Address : Dornierstr. 4, D-82178 Puchheim, Germany
>     <https://maps.google.com/?q=Dornierstr.+4,+D-82178+Puchheim,+Germany&entry=gmail&source=g>
>     Phone   : +49 89 189 47 41-16
>     Fax     : +49 89 189 47 41-09
>     E-Mail  : sebastian.huber at embedded-brains.de
>     <mailto:sebastian.huber at embedded-brains.de>
>     PGP     : Public key available on request.
>
>     Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
>
>     _______________________________________________
>     freebsd-hackers at freebsd.org <mailto:freebsd-hackers at freebsd.org>
>     mailing list
>     https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
>     <https://lists.freebsd.org/mailman/listinfo/freebsd-hackers>
>     To unsubscribe, send any mail to
>     "freebsd-hackers-unsubscribe at freebsd.org
>     <mailto:freebsd-hackers-unsubscribe at freebsd.org>"
>
>
> Additional information is available here : 
> http://concurrencykit.org/presentations/ebr.pdf 
> <http://concurrencykit.org/presentations/ebr.pdf>. The way I 
> understand it is that it is mostly used in place of read locks to 
> provide liveness guarantees without using atomics. Additional detail 
> is available in the commit messages. As an example see r333813 for 
> some performance data.
>

Thanks, for the reference. The "epoch reclamation" are good keywords to 
find more information.

What is the right mailing list to ask questions about the epoch 
implementation of the FreeBSD kernel?

To support this machinery in RTEMS is a bit difficult (in particular 
EPOCH_LOCKED). Since RTEMS is supposed to be a real-time operating 
system it supports only fixed-priority and job-level fixed priority 
(EDF) schedulers. To allow some scaling to larger SMP systems it 
supports clustered scheduling together with the mutual exclusion locking 
protocols MrsP (http://www-users.cs.york.ac.uk/~burns/MRSPpaper.pdf) and 
OMIP (http://www.mpi-sws.org/~bbb/papers/pdf/ecrts13b.pdf). This makes 
the thread pinning hard to implement (which is very easy to support in 
FreeBSD). The locking protocols may temporarily move a thread which owns 
a mutex to a foreign scheduler instance, e.g. a thread which wants to 
obtain the mutex helps the owner to make progress if it was pre-empted 
in its home scheduler instance. Due to a timeout of the helper the owner 
may loose the right to execute in the foreign scheduler instance. This 
would make it impossible to fulfil the processor pinning constraint 
(e.g. the thread priority in the foreign scheduler instance is undefined).

It would save me a lot of trouble if I could assume that EPOCH_LOCKED is 
an exotic feature which is unlikely to get used in FreeBSD.

-- 
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 at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.