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 54E3AC5479D for ; Tue, 3 Jan 2023 20:53:56 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id E2B1F8E0002; Tue, 3 Jan 2023 15:53:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id DE6038E0001; Tue, 3 Jan 2023 15:53:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id CA2F88E0002; Tue, 3 Jan 2023 15:53:55 -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 B564F8E0001 for ; Tue, 3 Jan 2023 15:53:55 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 8B1A7120B54 for ; Tue, 3 Jan 2023 20:53:55 +0000 (UTC) X-FDA: 80314689630.16.157AEB9 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf22.hostedemail.com (Postfix) with ESMTP id 76B2EC0014 for ; Tue, 3 Jan 2023 20:53:52 +0000 (UTC) Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=IjNwZnDc; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1672779233; 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=Y/BxhApXGBQSkvwGPdUVtQvXgrRE60w5clbCXLT5mVE=; b=vnwoz2X+XWb0PduGBMBduYXfts2P2lZ1wmK3vTZV0ncqvLepc+WZVVItSR1YBImWtG2tAI nPnf3/Kctwb7VpbUymYIuXun3oY1xpm1emf7/GyrfTQJ0ly5SyHHF9YCyE+nUkztsigZzu HQpRRZIScZa0AhqsYB7J/0j0VPsPmxM= ARC-Authentication-Results: i=1; imf22.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=IjNwZnDc; spf=none (imf22.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1672779233; a=rsa-sha256; cv=none; b=RgBVGsMrQhvRAG1ZDsmS/yyOoSbf1FZ9POjA4VnZ/8ssZwaessl2ado5zsy+ag0Slp4mV0 OeJrxWfzucGzHO87PYR/ChRClKFveOQ/AvoGGdSTUDEi/WlIpfW1YnEzHUTqm4mfcddvUc jKigWq5da1YgWr64/SEJLu+h3E7xsZo= 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=Y/BxhApXGBQSkvwGPdUVtQvXgrRE60w5clbCXLT5mVE=; b=IjNwZnDcV41tbThJhvL9M6k8BE lfROA+iOMY+Sq/4Nn+VhiuY81mClUBXyYAFUTDrji8HX8c5kKFLwdEjX1h2bAC5mx5eVCmQJeXWy3 Hq3ywXOCBRxCTFSx2Q1sBNqBrfPn7CQvCaJaLOKfcs4sSIJHZJFx3oMIylb39cfL3t+yx5UqGDMOr d47/+lED0aXpBIfLPar2Mqy4W2BHZNuWr8v3EeLNvs5myTtf2Sb95Z3Q62onzgALwxyGqP7jdEyBk ItAQvCiw0IVprLsCfhymyzbffRAnCprWiL5WD2+giHP3fQ9fSlPKZKBq6VV0qccyvJbjWA0JFx9l0 /GkwhozQ==; Received: from willy by casper.infradead.org with local (Exim 4.94.2 #2 (Red Hat Linux)) id 1pCoI7-00EP1J-Vk; Tue, 03 Jan 2023 20:53:48 +0000 Date: Tue, 3 Jan 2023 20:53:47 +0000 From: Matthew Wilcox To: Jaegeuk Kim Cc: "Vishal Moola (Oracle)" , chao@kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mm@kvack.org, fengnanchang@gmail.com, linux-fsdevel@vger.kernel.org Subject: Re: [RFC PATCH] f2fs: Convert f2fs_write_cache_pages() to use filemap_get_folios_tag() Message-ID: References: <0a95ba7b-9335-ce03-0f47-5d9f4cce988f@kernel.org> <20221212191317.9730-1-vishal.moola@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Queue-Id: 76B2EC0014 X-Stat-Signature: y8bigqqhbta4pzfefscwn4ne1ntb53cf X-Rspam-User: X-Rspamd-Server: rspam08 X-HE-Tag: 1672779232-971692 X-HE-Meta: U2FsdGVkX185QBdqI2h2uqde0AuHJV2qwbUumDI1/A9hmMv6/cYTGhSa5VA2S2HmnztaOdi6z4WnA0tYDfnH7neiaF4A1exROOrfC6GbELl3CsL1veLLUBGwWJYbXOu3hMrujYwC3X6AlKTSZ7QSJpx65I8eaypRshXN2NMw51V9cyUlOL5s/+itO9/PlVXqEz7+7Pu8gVtEqTjBsG7S4TjU9XjDIIDBIV3SwqH9XunErEHq9rn+2UePB3RS5WTle08Esz3xKLwv7SKWYp98cwr7DOBbpI9giaVDotm1ltYAkVMweObWAjSpijYTTSTe7zbTjh2LOoqHce9lXoP/Bf9Mxy5XajfaO3GCk+5PT6cBwWsFOpn1kQjNfFwRrnOlIGMJIIcRPy7lVr3eY66/PTz8mu3D0qWXQIOIYjupIyoKBcKaCU3ashFsl8zY34QSqApUm7TPlpT+jb7sWLmY6gakRSDnkC8OYTcXvQo/d5mqgfZxHd5/NIkqoM4M/m+W6yibIazX7Fe5RrILXuNDVuO/wkObi72Xaqb8bZ3Zrgn1/zbIhMvdmUhTkyqvOFsFpgksV/1BOrLXVL0ui2BdiKlucX9sjxkoD1Xmm2PZ/HTPIUCPh5ZBrRQSwEwFR2m4dUj8AWPWV3/SXsEbAA7GS0jtVZu52cJCPmXmJLC1NTEFFOjSCq7N5Q40apnnwl1aDXiAmww8sBpaK3Kqobr0Rx/IIbzi6zrtXV0xH+UUzftzZsGXn9fyVG7rLYNy8f6hqgrm4ekLjveKJbhFCYIl+hRZpiKksPZ75FTUmRAjmYXPjREDoJwitOTug+vr5n2fyVSlWv5SDXukV4crsu3FuiLDi9xxvHHVJTCO/XaFYrQi7chBE7otCgLj3GJ21OXmvtc0RmuOy2V2O3m5VcBM3ljmWQ3BDFYGMSCp6szO/clMSJV+rTEi0ByMxLeDpShksp7/6xPYhdsG3jfMRZo J9w== 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 Thu, Dec 15, 2022 at 11:02:24AM -0800, Jaegeuk Kim wrote: > On 12/12, Vishal Moola (Oracle) wrote: > > @@ -2994,13 +2998,38 @@ static int f2fs_write_cache_pages(struct address_space *mapping, > > tag_pages_for_writeback(mapping, index, end); > > done_index = index; > > while (!done && !retry && (index <= end)) { > > - nr_pages = find_get_pages_range_tag(mapping, &index, end, > > - tag, F2FS_ONSTACK_PAGES, pages); > > - if (nr_pages == 0) > > + nr_pages = 0; > > +again: > > + nr_folios = filemap_get_folios_tag(mapping, &index, end, > > + tag, &fbatch); > > Can't folio handle this internally with F2FS_ONSTACK_PAGES and pages? I really want to discourage filesystems from doing this kind of thing. The folio_batch is the natural size for doing batches of work, and having the consistency across all these APIs of passing in a folio_batch is quite valuable. I understand f2fs wants to get more memory in a single batch, but the right way to do that is to use larger folios.