Date: Mon, 12 Nov 2018 13:59:25 +0100 From: Hans Petter Selasky <hps@selasky.org> To: Matt Macy <mmacy@FreeBSD.org>, src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org Subject: Re: svn commit: r340097 - in head/sys: kern sys Message-ID: <cd5e354a-c4f5-1b3d-5cc3-e21536c0c304@selasky.org> In-Reply-To: <201811030343.wA33hXRD067832@repo.freebsd.org> References: <201811030343.wA33hXRD067832@repo.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 11/3/18 4:43 AM, Matt Macy wrote: > Author: mmacy > Date: Sat Nov 3 03:43:32 2018 > New Revision: 340097 > URL: https://svnweb.freebsd.org/changeset/base/340097 > > Log: > Convert epoch to read / write records per cpu > > In discussing D17503 "Run epoch calls sooner and more reliably" with > sbahra@ we came to the conclusion that epoch is currently misusing the > ck_epoch API. It isn't safe to do a "write side" operation (ck_epoch_call > or ck_epoch_poll) in the middle of a "read side" section. Since, by definition, > it's possible to be preempted during the middle of an EPOCH_PREEMPT > epoch the GC task might call ck_epoch_poll or another thread might call > ck_epoch_call on the same section. The right solution is ultimately to change > the way that ck_epoch works for this use case. However, as a stopgap for > 12 we agreed to simply have separate records for each use case. > > Tested by: pho@ > > MFC after: 3 days ^^^ not yet MFC'ed - any reason why not? --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?cd5e354a-c4f5-1b3d-5cc3-e21536c0c304>