From owner-svn-src-all@freebsd.org Tue Sep 17 02:10:39 2019 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 28937F3578 for ; Tue, 17 Sep 2019 02:10:39 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660041.outbound.protection.outlook.com [40.107.66.41]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46XRR21M4vz4PCR; Tue, 17 Sep 2019 02:10:37 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IGiQWyctk5o2Lq6edgMGyuE7nYouER8Y5FRmlNGqfr5sAZBRavKWlvWIeN50dH62x81/PwUQCKJq700K5g4kSqec8MrMXG4aD+0FGtFVWU6Sda63ARFnQmiQ/Yafwb6JXiwpt5z7r+AZYdgnxC5eZI+o+322l5LnBNpxisrn/4rNwUeIluvnCF/V2h0Z5f4akVsr3bbHy/p5Am3SO/iJ3Gpui3z/DJ3l0BrGsTgTDIyORXO5n0tlojAY+Mkug/P/6l+0MsF19ebPQ3LX/ztxgh4WFPNKqRmqCgbE6TPqoavyC1yQ/Nepry+BuF1xV9Jv1LbLaibMg6WsbDTJ5SC9oA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=F9PnDxaEkNaaFQ1IShCbUYBUSNdDjMH+dMU2lcr7ECI=; b=fwF8hbYJ4eQ/HTdZIsQ5IMKqePle+urXMHteV2RorEfVRlpAaWZTR0QcNvdb0r1485Q4jaeYIAsHQxtvKh2ltJ1UOOKiEGU+d3wiDidzz6ALPKJFxeANzcGz8T9uVwlDEgZv0SBHvd3/oGXDEORwypf33iYX+9LmmErWVN2gowTZQIlVkQjKz6WNNd/i1kVbYn2cIaUJFDGlDft4arQ5xXsHH0vTFFfq5cAa35s8xrRgTepn1EY7LuiCvMvy2a7n6azEL6ZgugxAkfVjgbeywykNu5zOXeTD+38PwBmB3IY+IY8gKq2iDVZzVFopXZozWKBMPOF6Wyoe+m1AY8qFGQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none Received: from YTXPR0101MB2189.CANPRD01.PROD.OUTLOOK.COM (52.132.39.22) by YTXPR0101MB0926.CANPRD01.PROD.OUTLOOK.COM (52.132.40.25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2263.17; Tue, 17 Sep 2019 02:10:36 +0000 Received: from YTXPR0101MB2189.CANPRD01.PROD.OUTLOOK.COM ([fe80::5413:22e8:7013:d8b9]) by YTXPR0101MB2189.CANPRD01.PROD.OUTLOOK.COM ([fe80::5413:22e8:7013:d8b9%5]) with mapi id 15.20.2263.023; Tue, 17 Sep 2019 02:10:36 +0000 From: Rick Macklem To: Konstantin Belousov CC: "peterj@freebsd.org" , "svn-src-all@freebsd.org" Subject: Re: Re; svn commit: r352393 - head/sys/fs/nfsclient Thread-Topic: Re; svn commit: r352393 - head/sys/fs/nfsclient Thread-Index: AQHVbKIrGKQ8rOwi4UavHi4KjNkUJKcueR6AgAClTws= Date: Tue, 17 Sep 2019 02:10:36 +0000 Message-ID: References: , <20190916161001.GV2559@kib.kiev.ua> In-Reply-To: <20190916161001.GV2559@kib.kiev.ua> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 744e273d-78ef-4252-36c8-08d73b143a97 x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(5600167)(711020)(4605104)(1401327)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(2017052603328)(7193020); SRVR:YTXPR0101MB0926; x-ms-traffictypediagnostic: YTXPR0101MB0926: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 01630974C0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(136003)(376002)(346002)(39860400002)(396003)(366004)(199004)(189003)(8676002)(8936002)(33656002)(478600001)(71200400001)(71190400001)(186003)(102836004)(6246003)(256004)(74316002)(25786009)(54906003)(2906002)(1411001)(11346002)(7696005)(99286004)(52536014)(76116006)(14454004)(26005)(6506007)(64756008)(66446008)(305945005)(9686003)(66476007)(66946007)(66556008)(86362001)(76176011)(6436002)(229853002)(446003)(476003)(486006)(55016002)(4326008)(14444005)(81166006)(81156014)(316002)(5660300002)(6916009)(786003); DIR:OUT; SFP:1101; SCL:1; SRVR:YTXPR0101MB0926; H:YTXPR0101MB2189.CANPRD01.PROD.OUTLOOK.COM; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: uoguelph.ca does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: 84I4Lu3NsFIByNmOCfwzktW0bQOew7N4X8ISHEj9Hj19P/rfaGVir33N6IBo9npXd+VfMgUO/qXPWao6y1m+RpMr336krAA37uof/jFWCxH2j45JXX5DfiLFd4Mn+XqN+bv7C4ribGUgO7mjS4Ss+lA+4+sC93kNIxyww+P4FZEu9iZoWYw+XJHy/Zm5NeEXuZWO+Q2EV64bIHV6sjVhkliJKnQA4wwXZ+f9G9mbvUSYwyHQNi3gj06o+uXhz7gbEnY+tnh6hxZA482PX23xzfg+WU5ggRMn2HVUSzLBwwSq5OCzY7zg9Dywj6SqBBfhk9yXIwfaYizphCVwWbv39/O7PaeQJ006l3bEXSqS+RSgWD2gSCH/komm0IY7dPMZCm3wr00R4bAk50i25v/dBIlvgy1JkIsWT8JfZYL7/c4= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-Network-Message-Id: 744e273d-78ef-4252-36c8-08d73b143a97 X-MS-Exchange-CrossTenant-originalarrivaltime: 17 Sep 2019 02:10:36.3298 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 4T5WFUv1QNBCpipy1hAjoR1XxfCUVEaQ+SrLxvJ7LQnPIanldJsxgKGr9C7MqRDZtKbkil4vN1cFopbmYeMbBg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YTXPR0101MB0926 X-Rspamd-Queue-Id: 46XRR21M4vz4PCR X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.41 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-4.54 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[uoguelph.ca]; TO_DN_SOME(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_IN_DNSWL_NONE(0.00)[41.66.107.40.list.dnswl.org : 127.0.3.0]; IP_SCORE(-1.24)[ipnet: 40.64.0.0/10(-3.65), asn: 8075(-2.51), country: US(-0.05)]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8075, ipnet:40.64.0.0/10, country:US]; ARC_ALLOW(-1.00)[i=1] 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: Tue, 17 Sep 2019 02:10:39 -0000 Konstantin Belousov wrote:=0A= >On Mon, Sep 16, 2019 at 03:27:02PM +0000, Rick Macklem wrote:=0A= >> Hi Kostik,=0A= >>=0A= >> I'm afraid there was a reason that only certain cases (where the file wa= s=0A= >> being shrunk) did the vnode_pager_setsize() call after the NFS node=0A= >> lock is released.=0A= >>=0A= >> See the commit log message for r252528.=0A= >>=0A= >> If vnode_pager_setsize() now acquires a sleep lock for the case where th= e=0A= >> size is increasing, it sounds like the NFS node lock will have to become= a=0A= >> sleep lock instead of a mutex.=0A= >> (If needed, I can get working on this in a day or two.)=0A= >I suspect that the reason for the bug mentioned in r252528 is the fact=0A= >that NFS calls vnode_pager_setsize() without owning the vnode lock. AFAIR= =0A= >this happens when iod thread performs RPCs. If you look at the start of= =0A= >the vnode_pager_setsize() function, you would note a commented out assert= =0A= >that the vnode is exclusively locked.=0A= >=0A= >Indeed, changing node lock to sleepable lock is a lot of work. But may=0A= >be we should get rid of this mutex at all ? If you state that we should= =0A= >change it to some sleepable lock, then vnode lock should already serve=0A= >the purpose.=0A= >=0A= >The only issue I see is that we would need to add missed vnode locks=0A= >acquires in iod, and upgrade vnode lock shared to exclusive as needed.=0A= >An ugly intermediate solution might be to make NFS vnode locks always=0A= >exclusive.=0A= Well, the reason that the readahead/writebehind RPCs done by the iod thread= s=0A= haven't acquired the vnode lock was to allow them to occur concurrently.=0A= --> Now that there are LK_SHARED vnode locks, those could be used for=0A= the readaheads.=0A= --> For writebehinds, which is where the file's size changes, holding an=0A= exclusive vnode lock for the entire RPC would serialize them and that= =0A= could be a large performance hit.=0A= --> However, holding an exclusive vnode lock for short periods (but n= ot=0A= while the RPC is being done on the server) should be ok.=0A= The NFS node mutex may still be needed to serialize use of fiel= ds=0A= in the NFS part of the vnode, but if the exclusive vnode lock c= an be=0A= held for the code section in question and the other places wher= e=0A= the n_size field is used (instead of depending on the NFS node = mutex),=0A= that should work, I think.=0A= --> I'll take a look at the code tomorrow.=0A= =0A= rick=0A=