Date: Wed, 22 Aug 2018 20:34:39 +0300 From: Konstantin Belousov <kostikbel@gmail.com> To: Matthew Macy <mmacy@freebsd.org> Cc: sebastian.huber@embedded-brains.de, freebsd-hackers@freebsd.org Subject: Re: epoch(9) background information? Message-ID: <20180822173439.GA2340@kib.kiev.ua> In-Reply-To: <CAPrugNp8NM5BbEzqf3pY5hGvfyrO7MnXXLiCfCyRxC3YMWzoWw@mail.gmail.com> References: <db397431-2c4c-64de-634a-20f38ce6a60e@embedded-brains.de> <CALX0vxBAN6nckuAnYR3_mOfwbCjJCjHGuuOFh9njpxO%2BGUzo3w@mail.gmail.com> <fc088eb4-f306-674c-7404-ebe17a60a5f8@embedded-brains.de> <CAPrugNp8NM5BbEzqf3pY5hGvfyrO7MnXXLiCfCyRxC3YMWzoWw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Aug 21, 2018 at 11:44:19PM -0700, Matthew Macy wrote: > EPOCH_LOCKED is something that one would only want to use in a fairly > narrow set of circumstances. The only place it's being discussed currently > is in pmap: > > https://reviews.freebsd.org/D15983 > > There it would conceivably replace a global mutex that currently serializes > all munmap operations. I have a scetchy design which keeps the current approach of waiting for delayed invalidation in the pmap_remove_all()/pmap_remove_write(), simultaneosly eliminating the global_invl_mtx mutex at all. There was some discussion about epoch vs. fine-graining of the existing DI code, relative to the moving the sleep time to pagedaemon threads. I did not have time to work it out (yet) due to personal issues.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180822173439.GA2340>