On 11/2/18 11:43 PM, Matt Macy wrote:
Author: mmacy
Date: Sat Nov 3 03:43:32 2018
New Revision: 340097
URL:
https://urldefense.proofpoint.com/v2/url?u=https-3A__svnweb.freebsd.org_changeset_base_340097&d=DwIDaQ&c=imBPVzF25OnBgGmVOlcsiEgHoG1i6YHLR0Sj_gZ4adc&r=Ed-falealxPeqc22ehgAUCLh8zlZbibZLSMWJeZro4A&m=C46M75X_gZcJY3aXGYy_P4DQJhD-uEFU00BP6AzHPik&s=JvPbkoXDB3zzo2IjmopaQxJ3kRcIwzosrpY4elq80LQ&e=
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
Hi Matt,
Can you elaborate why this is needed?
I seem to recall that Samy Al Bahra made some upstream changes to CK
that modified the CK API to legitimize our use of the API, and these
were brought into FreeBSD in r339375. Were these insufficient?
Also, it would be great if you could get review on epoch changes. Epoch
is totally awesome, and I'm thrilled that you brought it in. However,
it is very tricky, and it seems like changes here could benefit from review.
Thanks,
Drew
_______________________________________________
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
