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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 78DC4C04A68 for ; Thu, 28 Jul 2022 14:18:22 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230347AbiG1OSV (ORCPT ); Thu, 28 Jul 2022 10:18:21 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:47590 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229484AbiG1OSV (ORCPT ); Thu, 28 Jul 2022 10:18:21 -0400 Received: from casper.infradead.org (casper.infradead.org [IPv6:2001:8b0:10b:1236::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id C8E9252DDA; Thu, 28 Jul 2022 07:18:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; 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=6yJFmCjq7j3EiYzdT5riiMxTlawWcPIvBh3hMXTowos=; b=tDxZoPKAWg0/dgNc8WPgDxg/GU Cqip0gnoyz6wHT16FW+cISsYnciiRhJQJoGBhyEmDgr10vWdGHxQXgbeDwINuXO1kbuYeC/sjZeP2 YL5Bpzb4pLuVMHRMIHWGx6dbCQi7z1ISYzcN47FWNn18S3/wfhc0CFZHU9ceHq/TicqjYXSfKnnCt I0DHO+icFRZdgyIVmdT2GTmVVBn7V03KFoXARG+dX9D58LufJWqhEowXnKE+LUR4DRG9po0cLJxOp TYaxF9dYUmUynkBu2lr+XSm3QjPMO+x2rTqUDBoj57SfwUhRSelbReS+MITKMnHaLp4cre6i304W5 NZ9iEqTw==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1oH4Kx-003toI-8v; Thu, 28 Jul 2022 14:18:03 +0000 Date: Thu, 28 Jul 2022 15:18:03 +0100 From: Matthew Wilcox To: Jan Kara Cc: Christoph Hellwig , Bob Peterson , Andreas Gruenbacher , "Darrick J. Wong" , Damien Le Moal , Naohiro Aota , Johannes Thumshirn , cluster-devel@redhat.com, linux-xfs@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, Mel Gorman Subject: Re: remove iomap_writepage v2 Message-ID: References: <20220719041311.709250-1-hch@lst.de> <20220728111016.uwbaywprzkzne7ib@quack3> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220728111016.uwbaywprzkzne7ib@quack3> Precedence: bulk List-ID: X-Mailing-List: linux-xfs@vger.kernel.org On Thu, Jul 28, 2022 at 01:10:16PM +0200, Jan Kara wrote: > Hi Christoph! > > On Tue 19-07-22 06:13:07, Christoph Hellwig wrote: > > this series removes iomap_writepage and it's callers, following what xfs > > has been doing for a long time. > > So this effectively means "no writeback from page reclaim for these > filesystems" AFAICT (page migration of dirty pages seems to be handled by > iomap_migrate_page()) which is going to make life somewhat harder for > memory reclaim when memory pressure is high enough that dirty pages are > reaching end of the LRU list. I don't expect this to be a problem on big > machines but it could have some undesirable effects for small ones > (embedded, small VMs). I agree per-page writeback has been a bad idea for > efficiency reasons for at least last 10-15 years and most filesystems > stopped dealing with more complex situations (like block allocation) from > ->writepage() already quite a few years ago without any bug reports AFAIK. > So it all seems like a sensible idea from FS POV but are MM people on board > or at least aware of this movement in the fs land? I mentioned it during my folio session at LSFMM, but didn't put a huge emphasis on it. For XFS, writeback should already be in progress on other pages if we're getting to the point of trying to call ->writepage() in vmscan. Surely this is also true for other filesystems?