From owner-svn-src-all@freebsd.org Mon Nov 12 17:55:31 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 B78BA110CC16; Mon, 12 Nov 2018 17:55:31 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from duke.cs.duke.edu (duke.cs.duke.edu [152.3.140.1]) (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 DC85B7AC0D; Mon, 12 Nov 2018 17:55:30 +0000 (UTC) (envelope-from gallatin@cs.duke.edu) Received: from [192.168.200.4] (c-71-56-186-158.hsd1.va.comcast.net [71.56.186.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: gallatin) by duke.cs.duke.edu (Postfix) with ESMTPSA id 8DAB82700402; Mon, 12 Nov 2018 12:55:23 -0500 (EST) DMARC-Filter: OpenDMARC Filter v1.3.1 duke.cs.duke.edu 8DAB82700402 Authentication-Results: duke.cs.duke.edu; dmarc=none header.from=cs.duke.edu DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=cs.duke.edu; s=mail0816; t=1542045323; bh=IppCD6qPay/o7JCAMwc+AEV4vdwjnK7DmovNIzIU4wI=; h=Subject:To:From:Date:From; b=CiNlhcThP2x/9APxPH3XPJ9xfno4ngXshzQLubHCEcrQ8Gdsr5cOFxEioxsDxQUUN N0GLkWGO86PAzYxMotwyrMiHjzNySL/zJvStdSweGdCJUWBF/2bVbMIoJf7RI4xrfZ 3II4zCHWyfAtexOQczYGCpxuW9O04CRFeuyRtPDc/r8aLTu1jSRKKH2XKYvpNUeL2/ arx9QY8o15cVNInAKBB3lqTNcZqGCbwWZ/6YB6QB/pnKBnm5XopajwVAX5gJVrj9c7 XTzatn0HypH/mwCImqJpEwVpLnau8ZxgQ8LjkqWxzkAZCh7SGMy5nNvG2vY0rQYPRN v1whpdnvyBZxA== 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: Andrew Gallatin Message-ID: Date: Mon, 12 Nov 2018 12:55:22 -0500 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.3.0 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: DC85B7AC0D X-Spamd-Result: default: False [-3.41 / 200.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_DKIM_ALLOW(-0.20)[cs.duke.edu]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; R_SPF_ALLOW(-0.20)[+ip4:152.3.140.0/23]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(0.31)[0.313,0]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.999,0]; RCVD_IN_DNSWL_MED(-0.20)[1.140.3.152.list.dnswl.org : 127.0.11.2]; DKIM_TRACE(0.00)[cs.duke.edu:+]; DMARC_POLICY_ALLOW(-0.50)[cs.duke.edu,none]; MX_GOOD(-0.01)[mx.oit.duke.edu]; FROM_EQ_ENVFROM(0.00)[]; IP_SCORE(-0.02)[country: US(-0.09)]; ASN(0.00)[asn:13371, ipnet:152.3.128.0/17, country:US]; 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 17:55:32 -0000 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