epoch(9) background information?

[Sebastian Huber]

On 22/08/18 08:49, Matthew Macy wrote:
>
>
> On Tue, Aug 21, 2018 at 11:42 PM Sebastian Huber 
> <sebastian.huber at embedded-brains.de 
> <mailto:sebastian.huber at embedded-brains.de>> wrote:
>
>     On 22/08/18 08:34, Sebastian Huber wrote:
>     > 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>
>     >> <mailto: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>
>     >>     <mailto: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>
>     <mailto: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>
>     >>     <mailto: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
>     <http://www-users.cs.york.ac.uk/%7Eburns/MRSPpaper.pdf>) and OMIP
>     > (http://www.mpi-sws.org/~bbb/papers/pdf/ecrts13b.pdf
>     <http://www.mpi-sws.org/%7Ebbb/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.
>     >
>
>     Another question, is it a common use case to call
>     epoch_enter_preempt()
>     and epoch_exit_preempt() while owning a mutex?
>
>
> Yes. Very. It is generally not permitted to hold a mutex across 
> epoch_wait() that's why there's the special flag EPOCH_LOCKED. If you 
> have a very limited number of threads, you might want to have each 
> thread have its own record registered with the epoch. Then you 
> wouldn't need the CPU pinning. The pinning is just away of providing a 
> limited number of records to an unbounded number of threads.

Thanks for the prompt answer.

Do I need a record per thread and per epoch? Could I use only one (maybe 
dependent on the nest level?) record per thread?

-- 
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.