From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 379BBC433F5 for ; Mon, 24 Jan 2022 08:55:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C8BA46B0083; Mon, 24 Jan 2022 03:55:10 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C3AF76B0085; Mon, 24 Jan 2022 03:55:10 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id B29E26B0087; Mon, 24 Jan 2022 03:55:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0172.hostedemail.com [216.40.44.172]) by kanga.kvack.org (Postfix) with ESMTP id A49276B0083 for ; Mon, 24 Jan 2022 03:55:10 -0500 (EST) Received: from smtpin13.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay02.hostedemail.com (Postfix) with ESMTP id 5EEC390087 for ; Mon, 24 Jan 2022 08:55:10 +0000 (UTC) X-FDA: 79064571180.13.E09FABE Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) by imf13.hostedemail.com (Postfix) with ESMTP id 1A06F20006 for ; Mon, 24 Jan 2022 08:55:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20210309; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=vEv9ZVm4FRM2sWGecomArAPFZr2kyAtBIJ0fxjajhKA=; b=H520EeGELfNL68TKhbR92ln0dj XKvss8VcBEDNoQ8IRsEHC5Wwef5wjYXkCSmd9tPqTyDiUbXXXjcDXRcWvQjsAFzzDMTFN4mMGjmIf SUsKICrwuxD1wFtrjEGhufCiem0oB15dmWprRtT6QOTfvKiR8zrvt6DYpBcQSLmbiggt/CdKWlynh 9uR7RpkH9ZF+99bWbuYig7PgQkrSgajZptg0FHNc/7GAsS4/eSsqPxNOPhXKk6/K06V+V6Z6uZNL6 5tEqauSzJYFpARpTU4iOgzctaXwD0I4VQ5ddz4A1dpELojqG4BxTGYlVJz18fx3Y7Sh2kAuXgYHMl EnfgFUHA==; Received: from hch by bombadil.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1nBv7u-002gVx-V2; Mon, 24 Jan 2022 08:55:02 +0000 Date: Mon, 24 Jan 2022 00:55:02 -0800 From: Christoph Hellwig To: NeilBrown Cc: Trond Myklebust , Anna Schumaker , Chuck Lever , Andrew Morton , Mel Gorman , Christoph Hellwig , David Howells , linux-nfs@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 10/23] MM: submit multipage write for SWP_FS_OPS swap-space Message-ID: References: <164299573337.26253.7538614611220034049.stgit@noble.brown> <164299611279.26253.12350012848236496937.stgit@noble.brown> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <164299611279.26253.12350012848236496937.stgit@noble.brown> X-SRS-Rewrite: SMTP reverse-path rewritten from by bombadil.infradead.org. See http://www.infradead.org/rpr.html Authentication-Results: imf13.hostedemail.com; dkim=pass header.d=infradead.org header.s=bombadil.20210309 header.b=H520EeGE; spf=none (imf13.hostedemail.com: domain of BATV+b18af077b488c69bdec9+6728+infradead.org+hch@bombadil.srs.infradead.org has no SPF policy when checking 198.137.202.133) smtp.mailfrom=BATV+b18af077b488c69bdec9+6728+infradead.org+hch@bombadil.srs.infradead.org; dmarc=none X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 1A06F20006 X-Stat-Signature: s5qqn1qg89dmp9x1np4knaekc6tjp96t X-HE-Tag: 1643014509-249265 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On Mon, Jan 24, 2022 at 02:48:32PM +1100, NeilBrown wrote: > swap_writepage() is given one page at a time, but may be called repeatedly > in succession. > For block-device swapspace, the blk_plug functionality allows the > multiple pages to be combined together at lower layers. > That cannot be used for SWP_FS_OPS as blk_plug may not exist - it is > only active when CONFIG_BLOCK=y. Consequently all swap reads over NFS > are single page reads. > > With this patch we pass a pointer-to-pointer via the wbc. > swap_writepage can store state between calls - much like the pointer > passed explicitly to swap_readpage. After calling swap_writepage() some > number of times, the state will be passed to swap_write_unplug() which > can submit the combined request. > > Signed-off-by: NeilBrown > --- > include/linux/writeback.h | 7 +++ > mm/page_io.c | 103 +++++++++++++++++++++++++++++---------------- > mm/swap.h | 1 > mm/vmscan.c | 9 +++- > 4 files changed, 82 insertions(+), 38 deletions(-) > > diff --git a/include/linux/writeback.h b/include/linux/writeback.h > index fec248ab1fec..6dcaa0639c0d 100644 > --- a/include/linux/writeback.h > +++ b/include/linux/writeback.h > @@ -80,6 +80,13 @@ struct writeback_control { > > unsigned punt_to_cgroup:1; /* cgrp punting, see __REQ_CGROUP_PUNT */ > > + /* To enable batching of swap writes to non-block-device backends, > + * "plug" can be set point to a 'struct swap_iocb *'. When all swap > + * writes have been submitted, if with swap_iocb is not NULL, > + * swap_write_unplug() should be called. > + */ > + struct swap_iocb **plug; Mayb plug isn't really the best name for something swap-specific in this generic structure? Also the above does not fit the normal kernel comment style with an otherwise empty /* line. > + for (p = 0; p < sio->pages; p++) { > + struct page *page = sio->bvec[p].bv_page; > + > + if (ret != 0 && ret != PAGE_SIZE * sio->pages) { > + /* > + * In the case of swap-over-nfs, this can be a > + * temporary failure if the system has limited > + * memory for allocating transmit buffers. > + * Mark the page dirty and avoid > + * folio_rotate_reclaimable but rate-limit the > + * messages but do not flag PageError like > + * the normal direct-to-bio case as it could > + * be temporary. > + */ > + set_page_dirty(page); > + ClearPageReclaim(page); > + pr_err_ratelimited("Write error %ld on dio swapfile (%llu)\n", > + ret, page_file_offset(page)); > + } else > + count_vm_event(PSWPOUT); I'd rather check for the error condition ones and have separate loops forthe success vs error cases instead of checking the condition again and again. Otherwise looks good: Reviewed-by: Christoph Hellwig