From owner-svn-src-all@freebsd.org Mon Nov 12 13:00:09 2018 Return-Path: Delivered-To: svn-src-all@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9DE6611057EF; Mon, 12 Nov 2018 13:00:09 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id ACCD16E2F4; Mon, 12 Nov 2018 13:00:08 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [178.17.145.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 01E922603DA; Mon, 12 Nov 2018 13:59:58 +0100 (CET) Subject: Re: svn commit: r340097 - in head/sys: kern sys To: Matt Macy , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-head@freebsd.org References: <201811030343.wA33hXRD067832@repo.freebsd.org> From: Hans Petter Selasky Message-ID: Date: Mon, 12 Nov 2018 13:59:25 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.0.1 MIME-Version: 1.0 In-Reply-To: <201811030343.wA33hXRD067832@repo.freebsd.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: ACCD16E2F4 X-Spamd-Result: default: False [-4.80 / 200.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+a:mail.turbocat.net]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[selasky.org]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; TO_DN_SOME(0.00)[]; MX_GOOD(-0.01)[mail.turbocat.net]; NEURAL_HAM_SHORT(-0.92)[-0.925,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; IP_SCORE(-1.56)[ipnet: 88.99.0.0/16(-4.86), asn: 24940(-2.93), country: DE(-0.02)]; ASN(0.00)[asn:24940, ipnet:88.99.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Server: mx1.freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2018 13:00:09 -0000 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