Date: Fri, 27 Dec 2019 13:17:14 +0100 From: Mateusz Guzik <mjguzik@gmail.com> To: Hans Petter Selasky <hps@selasky.org> Cc: Ronald Klop <ronald-lists@klop.ws>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r356120 - head/sys/security/mac Message-ID: <CAGudoHGUJC68w6zGUaes8z95kxy2rQ-%2B2PJjW68tTozFMObPsA@mail.gmail.com> In-Reply-To: <053d786b-b3ed-53e3-e863-45801dbcd933@selasky.org> References: <201912271123.xBRBNWow013539@repo.freebsd.org> <op.0dgfqujxkndu52@sjakie> <053d786b-b3ed-53e3-e863-45801dbcd933@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 12/27/19, Hans Petter Selasky <hps@selasky.org> wrote: > On 2019-12-27 12:33, Ronald Klop wrote: >> Wow, this looks like a winner. >> >> Ronald. > > Is this a spin-off from epoch methodology? > > It is possible to use epoch as a part of read mostly locking too. > epoch uses explicit fences which are a completely unnecessary cost for this usecase. This is rmlocks with priority propagation removed and with an extra hack to signal do send extra IPIs if any of the target CPUs got caught in executing the fast path. -- Mateusz Guzik <mjguzik gmail.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAGudoHGUJC68w6zGUaes8z95kxy2rQ-%2B2PJjW68tTozFMObPsA>