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 C6D54C433FE for ; Wed, 16 Nov 2022 18:39:09 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 467A48E0001; Wed, 16 Nov 2022 13:39:09 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 417A86B0075; Wed, 16 Nov 2022 13:39:09 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 306898E0001; Wed, 16 Nov 2022 13:39:09 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 222FD6B0074 for ; Wed, 16 Nov 2022 13:39:09 -0500 (EST) Received: from smtpin19.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id C6E7F140854 for ; Wed, 16 Nov 2022 18:39:08 +0000 (UTC) X-FDA: 80140167576.19.B479611 Received: from mail-pg1-f174.google.com (mail-pg1-f174.google.com [209.85.215.174]) by imf05.hostedemail.com (Postfix) with ESMTP id 65F6D100007 for ; Wed, 16 Nov 2022 18:39:08 +0000 (UTC) Received: by mail-pg1-f174.google.com with SMTP id v3so17480342pgh.4 for ; Wed, 16 Nov 2022 10:39:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=hYF3Hj9rSyQp4X4qzG1/mtul7nlvlXjBvw9fIIZhTos=; b=X/3VlFQOq/F4K880LRk9TjjvLSZlvu7/kRCnM9p5B3rYiLfewmE7LcvkodiAPiM7DU raLagsEw7CdstzIfRRDQz9Le/ayij3LC1LTJRZHZxZkqIdDJj+AgU3FGWfWpEYNI63hd JHT6SvBQ94N/ok8vRWKDzFTw0PvRImdHoqK9ezlfgiLhWQpzYE91xtGeyNwOlJistHMc UGjhbEzpM/cIjmxjL/mrzcDHpeePSLDv0f7N4d6JVNznieNE4hs4/NJOZBhlox3hzYej zUlZxtCAbtrkFHhBGxuKAuuS96kObNhGGMwm9Pv+FlRMqdlXaO+8r+jE/zxwLpwZYYsk NOPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=hYF3Hj9rSyQp4X4qzG1/mtul7nlvlXjBvw9fIIZhTos=; b=tUDp5a+FemHOmFyd0+QIltpEnVwu67olQTWl9rKwsqAJmu8UAce9Y5JYpk3Bcpy/am BOAd84eGDlxcznC3YcVK+/rLe5iCbLOZGV9/utcWUIlqvVKeswVksBucyVrtF9ubXn9k PTbcxve2fFkQBBqX53tjhosfDdn1x7WqFTq6CdlvqfPj7Aj/LE09Z6IOEgYhj0ar4qdK U5vEjzDCIFqpMpNSQ51ocVekIdpCKE0ge3XQaTK5TPJ9+9fziYbsK/I8DfaQq0nVC4Oi Dn8/v40jFUFZSIFwUkumhl+6Tt/97sFF6CN6dKXXy9KIeLEH/yPBlQgC60E4MkL33f6C SVtg== X-Gm-Message-State: ANoB5pm+snIZxYII3EFePuaveCCsebefLSR2QdRi/mf0amJYZo92gQvM Ve4XnqbKCjlymFmIxg8MCaM/VwHERn8= X-Google-Smtp-Source: AA0mqf5CWC9cDzSsVhgoM5hzB1p88qRacHWHl2gRD4exiTbTBQYf+GC47C06p+H1E34QifQ+npSGkQ== X-Received: by 2002:a62:1ad4:0:b0:56b:add7:fe2f with SMTP id a203-20020a621ad4000000b0056badd7fe2fmr24188517pfa.51.1668623947228; Wed, 16 Nov 2022 10:39:07 -0800 (PST) Received: from localhost ([2406:7400:63:f20b:f6ca:e236:f59f:8c18]) by smtp.gmail.com with ESMTPSA id a4-20020aa795a4000000b0056d7cc80ea4sm11234366pfk.110.2022.11.16.10.39.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 16 Nov 2022 10:39:06 -0800 (PST) Date: Thu, 17 Nov 2022 00:09:00 +0530 From: "Ritesh Harjani (IBM)" To: Christoph Hellwig Cc: Namjae Jeon , Sungjong Seo , Jan Kara , OGAWA Hirofumi , Mikulas Patocka , Dave Kleikamp , Bob Copeland , linux-fsdevel@vger.kernel.org, linux-ext4@vger.kernel.org, jfs-discussion@lists.sourceforge.net, linux-karma-devel@lists.sourceforge.net, linux-mm@kvack.org Subject: Re: start removing writepage instances Message-ID: <20221116183900.yzpcymelnnwppoh7@riteshh-domain> References: <20221113162902.883850-1-hch@lst.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20221113162902.883850-1-hch@lst.de> ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1668623948; a=rsa-sha256; cv=none; b=kx0J1OPMrWaC8PXRr3J0uopnfsx6hzL6hsjb/NGtQ1KtLUTWhrN1SGvglSM6wsG1sRdSXf vKhc7MFobiasDs+TCPdZkXfor2umYIQ3QUcwxoGve3cV1KBi1Yb32icfwHjqF7qktKHP+9 A4u9sKUh4PYa+MZX6w2ZhKN9bnp+HvY= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="X/3VlFQO"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf05.hostedemail.com: domain of ritesh.list@gmail.com designates 209.85.215.174 as permitted sender) smtp.mailfrom=ritesh.list@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1668623948; h=from:from:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:content-transfer-encoding: in-reply-to:in-reply-to:references:references:dkim-signature; bh=hYF3Hj9rSyQp4X4qzG1/mtul7nlvlXjBvw9fIIZhTos=; b=2vwayJvPVv9NZJZJv+PViJE2fSQZlTYZ3IaiJHSro/6v6ov09hnfgonHFR5JO9sDYafVJa 6Crs3S/2ak2QTyqMu0pplmlzmFO6eA3U1BYpYWmqreaPRwyiRFxqttpnIXWB1wDPjYgvju 8Hc47sdt/PxFi2VYVTbr9yEUwULOFnU= X-Stat-Signature: kd8uuxo7h3njbddcacepwyegkfudcpkj X-Rspamd-Queue-Id: 65F6D100007 Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=gmail.com header.s=20210112 header.b="X/3VlFQO"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf05.hostedemail.com: domain of ritesh.list@gmail.com designates 209.85.215.174 as permitted sender) smtp.mailfrom=ritesh.list@gmail.com X-Rspam-User: X-Rspamd-Server: rspam12 X-HE-Tag: 1668623948-507055 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 22/11/13 05:28PM, Christoph Hellwig wrote: > Hi all, > > The VM doesn't need or want ->writepage for writeback and is fine with > just having ->writepages as long as ->migrate_folio is implemented. Ok, so here is, (what I think) is the motivation for doing this. Please correct me if this is incorrect... 1. writepage is mainly called from pageout, which happens as part of the memory reclaim. Now IIUC from previous discussions [1][2][3], reclaims happens from the tail end of the LRU list which could do an I/O of a single page while an ongoing writeback was in progress of multiple pages. This disrupts the I/O pattern to become more random in nature, compared to, if we would have let writeback/flusher do it's job of writing back dirty pages. Also many filesystems behave very differently within their ->writepage calls, e.g. ext4 doesn't actually write in ->writepage for DELAYED blocks. 2. Now the other place from where ->writepage can be called from is, writeout() function, which is a fallback function for migration (fallback_migrate_folio()). fallback_migrate_folio() is called from move_to_new_folio() if ->migrate_folio is not defined for the FS. So what you are doing here is removing the ->writepage from address_space operations of the filesystems which implements ->writepage using block_write_full_page() (i.e. those who uses buffer_heads). This is done for those FS who already have ->migrate_folio() implemented (hence no need of ->writepage). ...Now this is also a step towards reducing the callers from kernel which uses buffer_heads. [1]: https://lore.kernel.org/all/1310567487-15367-1-git-send-email-mgorman@suse.de/ [2]: https://lore.kernel.org/all/20181107063127.3902-2-david@fromorbit.com/ [3]: https://lore.kernel.org/all/1271117878-19274-1-git-send-email-david@fromorbit.com/ Is above a correct understanding? > > This series removes all ->writepage instances that use > block_write_full_page directly and also have a plain mpage_writepages > based ->writepages. Ok. > > Diffstat: > fs/exfat/inode.c | 9 ++------- > fs/ext2/inode.c | 6 ------ > fs/fat/inode.c | 9 ++------- > fs/hfs/inode.c | 2 +- > fs/hfsplus/inode.c | 2 +- > fs/hpfs/file.c | 9 ++------- > fs/jfs/inode.c | 7 +------ > fs/omfs/file.c | 7 +------ > fs/udf/inode.c | 7 +------ > 9 files changed, 11 insertions(+), 47 deletions(-)