Date: Tue, 21 Aug 2018 23:49:26 -0700 From: Matthew Macy <mmacy@freebsd.org> To: sebastian.huber@embedded-brains.de Cc: freebsd-hackers@freebsd.org Subject: Re: epoch(9) background information? Message-ID: <CAPrugNpZ5CihCW6hz3ztXAZrNn1qJNRsE=yGCvw1rzqNPQYRvg@mail.gmail.com> In-Reply-To: <15e3f080-2f82-a243-80e9-f0a916445828@embedded-brains.de> References: <db397431-2c4c-64de-634a-20f38ce6a60e@embedded-brains.de> <CALX0vxBAN6nckuAnYR3_mOfwbCjJCjHGuuOFh9njpxO%2BGUzo3w@mail.gmail.com> <fc088eb4-f306-674c-7404-ebe17a60a5f8@embedded-brains.de> <15e3f080-2f82-a243-80e9-f0a916445828@embedded-brains.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 21, 2018 at 11:42 PM Sebastian Huber < sebastian.huber@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@embedded-brains.de > >> <mailto:sebastian.huber@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=3DDornierstr.+4,+D-82178+Puchheim,+Germany&ent= ry=3Dgmail&source=3Dg > > > >> Phone : +49 89 189 47 41-16 > >> Fax : +49 89 189 47 41-09 > >> E-Mail : sebastian.huber@embedded-brains.de > >> <mailto:sebastian.huber@embedded-brains.de> > >> PGP : Public key available on request. > >> > >> Diese Nachricht ist keine gesch=C3=A4ftliche Mitteilung im Sinne d= es > >> EHUG. > >> > >> _______________________________________________ > >> freebsd-hackers@freebsd.org <mailto:freebsd-hackers@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@freebsd.org > >> <mailto:freebsd-hackers-unsubscribe@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. -M
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPrugNpZ5CihCW6hz3ztXAZrNn1qJNRsE=yGCvw1rzqNPQYRvg>