epoch(9) background information?

[Julian Elischer]

On 21/8/18 11:49 pm, Matthew Macy wrote:
> On Tue, Aug 21, 2018 at 11:42 PM Sebastian Huber <
> 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>> 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.
>>>
>> 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.
Matt, could you add information about this in locking(9)?

it holds information on the interaction between various locking types 
and it woudl apear this needs to be added to the mix.

Julian
>
> -M
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
>
>