Received-SPF: pass (google.com: domain of linux-nfs-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
From:   Chuck Lever III <chuck.lever@oracle.com>
To:     Jeff Layton <jlayton@kernel.org>
CC:     Linux NFS Mailing List <linux-nfs@vger.kernel.org>,
        Neil Brown <neilb@suse.de>
Subject: Re: [PATCH v3 4/4] nfsd: start non-blocking writeback after adding
 nfsd_file to the LRU
Thread-Topic: [PATCH v3 4/4] nfsd: start non-blocking writeback after adding
 nfsd_file to the LRU
Thread-Index: AQHY6v8cX8B2IAnCiUGFnEk+Gt8JNK4kNxkA
Date:   Fri, 28 Oct 2022 19:50:39 +0000
Message-ID: <89288CA4-F679-482C-B9D1-68C583D7F5BA@oracle.com>
References: <20221028185712.79863-1-jlayton@kernel.org>
 <20221028185712.79863-5-jlayton@kernel.org>
In-Reply-To: <20221028185712.79863-5-jlayton@kernel.org>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?kms5VAXmYeU6T4iczibeA6r9Os/Mus3jp4BHZ3y7sDR2O8dvysnjlbKztn6J?=
 =?us-ascii?Q?90uCyobjFHqDp4FWWDLy3YTsrnR5w4FEDfMz9AVT9ZCRJKRMTFM8jvO1Awbh?=
 =?us-ascii?Q?pGvFX36bs2bC2FkE8kWiDXtuiDn7XszOLaz+Dxw8lgFfAcbODjhxuggYlByy?=
 =?us-ascii?Q?0n+JqeNsLTA1cxjyiW1KILWe/cm3Jq5zIpAbv0iOXtkLn40CQUX7GIbGoUmd?=
 =?us-ascii?Q?EpG7RDIW7lYy9v1U1eQ/f5vU9zDhkOqR6eevngIVkhI9SK+bN0Ryff7ZL60c?=
 =?us-ascii?Q?i9JsXaDZfxy+68H45oZHpU2BjRSvqgxozhW/ijBcPETJ8jGA5hXpi3woFhzx?=
 =?us-ascii?Q?UGphjGfaAi6QQGptNOE8+XQj/pbXfHiwwXbEkMcOd5vQcHgPXj7kxZe6W8Kn?=
 =?us-ascii?Q?9qL22lmi+LUrniGmNy83eAGeCJJpMQLpbIuKt6y7CSsatbQ44ocz/Tek/0NQ?=
 =?us-ascii?Q?/4/yWwn2yPB15tpw9XkqXsy2ktAl8auLTT6ncX8We2uo0VJYLHJI6xSUm5b/?=
 =?us-ascii?Q?t+OT0fDtc4TNYKBFSOKITJYpdiRJpqZhmHkzmce0XD8Dcd4nKQoZ2y1u8BZF?=
 =?us-ascii?Q?GewJqawR3HnrnQXZIaLJpYNRhThSrUi3OGQfjfiNLJ+V4qPoV6wj1/sxkkCZ?=
 =?us-ascii?Q?HKJCZ0Chmd3hgpUGK7SG1WBizCE7pUnDfMFt4jHGtOZSRgboEEESGo17eqvL?=
 =?us-ascii?Q?AR7vN//BS6z9j7m/EOSLReJaJjNI4J9FL26IGXJp8y9MRGjG7ddn8d0ZV93/?=
 =?us-ascii?Q?xW1xbWuJOXE/1Ce8OrR6ufw5jV8tb7Fg3a7d4rqrSivr4E4WObg5p52tsRnb?=
 =?us-ascii?Q?E5rSmMI2KENG+BaFoBucMIOQNHPvYnoi07Au1nfem0/2+08+uiXCMaoE43VD?=
 =?us-ascii?Q?v1RgP2fbup+DIBLm9Pr0l675tBeQjjuA+ff1TCDvQdGumVDjlALVPhUbNsg8?=
 =?us-ascii?Q?OM5sJcWejdrkXRJQk1uUZvwGmJIwHpLKAKiRTMfmjjAES52UB2rd0DTMg9xY?=
 =?us-ascii?Q?3Hii4egkqunQaQwUf6dk8puz3r8K7buyzypTVlUNqfuSH3QrOHWCyXAj94CQ?=
 =?us-ascii?Q?zYdTg6qaPek1ZisN956a05xBK1xDAn+g/oBQuTEGtJFOjbBCnJJfXSpGfSw5?=
 =?us-ascii?Q?zHnbKS5/FYFeP3VT4zBo1TxJEIozwvVuc5eX/A6K/aFJDRpaNbHb3Jyq1Tz0?=
 =?us-ascii?Q?XqBaj+U8tsOP7i01sKbzd3UrLspO8o7OiD5V1lDAGPBHFzCE0id1wvLKfJVp?=
 =?us-ascii?Q?agWM97luCkbipozvIASipXzBY5pCqxmn+RVDaiw3HWr8VxcVjH7SFW+Z8O0l?=
 =?us-ascii?Q?FvubzkE1UR+KatoD27tpkE8YKCBoKLw5DkTeDBdpNriCE2rWOMLLt16nRPAT?=
 =?us-ascii?Q?Tpar6eY/owobiblWKUw2quBOdIVlD7nlbpeqhm7B95H67Uxq2HkTPki6j17M?=
 =?us-ascii?Q?LJhzFBNRB6dN4ktZt6rXg2UO+jqd0pAJTmoaLhm4xBQ5PpDcwUKcHHNcxgr+?=
 =?us-ascii?Q?wrnNmB12sm5ANN//m6Uh2lWWHXqwSfMAruYyPFlri3UiQzqu/HZFw7zsqRWZ?=
 =?us-ascii?Q?Di5Mv/A4TbBLWG25xovhyKVt+fjI+89JugG210x5Tvcn4XRz3zgdDiKoGNYI?=
 =?us-ascii?Q?tA=3D=3D?=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <80B87AD551CACA4186DEDA7177D8B5DA@namprd10.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: BN0PR10MB5128.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 3627d9c0-ea25-4669-2391-08dab91db072
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Oct 2022 19:50:39.1494
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: HUARP2SlLjgoNp1Nhy4f+bvykrlzP3fH4nb844LKLEJZEnP+GSqxD8clNbvDzDKhA4moooqhEnR8ZYKL4qcx6A==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM4PR10MB6086
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.205,Aquarius:18.0.895,Hydra:6.0.545,FMLib:17.11.122.1
 definitions=2022-10-28_10,2022-10-27_01,2022-06-22_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 mlxscore=0 mlxlogscore=999
 spamscore=0 phishscore=0 bulkscore=0 malwarescore=0 suspectscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2210170000
 definitions=main-2210280125
X-Proofpoint-GUID: fECJvLCzGitM74MkDcHk07GXn-beschX
X-Proofpoint-ORIG-GUID: fECJvLCzGitM74MkDcHk07GXn-beschX
X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,
        DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW,
        RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE autolearn=ham
        autolearn_force=no version=3.4.6
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
        lindbergh.monkeyblade.net
Precedence: bulk
List-ID: <linux-nfs.vger.kernel.org>
X-Mailing-List: linux-nfs@vger.kernel.org


> On Oct 28, 2022, at 2:57 PM, Jeff Layton <jlayton@kernel.org> wrote:
>=20
> When a GC entry gets added to the LRU, kick off SYNC_NONE writeback
> so that we can be ready to close it when the time comes. This should
> help minimize delays when freeing objects reaped from the LRU.
>=20
> Signed-off-by: Jeff Layton <jlayton@kernel.org>
> ---
> fs/nfsd/filecache.c | 23 +++++++++++++++++++++--
> 1 file changed, 21 insertions(+), 2 deletions(-)
>=20
> diff --git a/fs/nfsd/filecache.c b/fs/nfsd/filecache.c
> index 47cdc6129a7b..c43b6cff03e2 100644
> --- a/fs/nfsd/filecache.c
> +++ b/fs/nfsd/filecache.c
> @@ -325,6 +325,20 @@ nfsd_file_fsync(struct nfsd_file *nf)
> 		nfsd_reset_write_verifier(net_generic(nf->nf_net, nfsd_net_id));
> }
>=20
> +static void
> +nfsd_file_flush(struct nfsd_file *nf)
> +{
> +	struct file *file =3D nf->nf_file;
> +	struct address_space *mapping;
> +
> +	if (!file || !(file->f_mode & FMODE_WRITE))
> +		return;
> +
> +	mapping =3D file->f_mapping;
> +	if (mapping_tagged(mapping, PAGECACHE_TAG_DIRTY))
> +		filemap_flush(mapping);
> +}
> +
> static int
> nfsd_file_check_write_error(struct nfsd_file *nf)
> {
> @@ -484,9 +498,14 @@ nfsd_file_put(struct nfsd_file *nf)
>=20
> 		/* Try to add it to the LRU.  If that fails, decrement. */
> 		if (nfsd_file_lru_add(nf)) {
> -			/* If it's still hashed, we're done */
> -			if (test_bit(NFSD_FILE_HASHED, &nf->nf_flags))
> +			/*
> +			 * If it's still hashed, we can just return now,
> +			 * after kicking off SYNC_NONE writeback.
> +			 */
> +			if (test_bit(NFSD_FILE_HASHED, &nf->nf_flags)) {
> +				nfsd_file_flush(nf);
> 				return;
> +			}

nfsd_write() calls nfsd_file_put() after every nfsd_vfs_write(). In some
cases, this new logic adds an async flush after every UNSTABLE NFSv3 WRITE.

I'll need to see performance measurements demonstrating no negative
impact on throughput or latency of NFSv3 WRITEs with large payloads.


> 			/*
> 			 * We're racing with unhashing, so try to remove it from
> --=20
> 2.37.3
>=20

--
Chuck Lever