From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 1B66B2773CA; Tue, 26 May 2026 02:31:16 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=90.155.50.34 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779762681; cv=none; b=GPkl4iX4YMHHz+9RLIsznak8HB8vZI694nqYGWz1loS6FaY6efnEMIkYBFlMeVBcOVEJGN4J7qoelM93HiKvDT4yJ7EguEP7IVZJfh5tTnni00QlHnNCBCBJyedhKFly0SZ2ofoEAob3ITkcTu5sgwapCV1rvIIc08kbP0KDo38= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1779762681; c=relaxed/simple; bh=R6sxRuIuRceAwwC/x+ybkOPbvLytTks6kPSwd8+3v7I=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=R8GDnteDNhH7P/98GqtYSd5kklHUo+C16GmLmMIWArtx/1ojV2aZuFXYtRcwpFDMBo/iG3X4oasZx4CVE7r0cYB6U/08beLsCHSIJsJzG0llyCVMgFLtYEZL2z/MwSoDfsex8AWQKZ7IjyUM122uN91XVrvuUQ71AR/NcTbm2RI= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org; spf=none smtp.mailfrom=infradead.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b=KBdxftb+; arc=none smtp.client-ip=90.155.50.34 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=infradead.org Authentication-Results: smtp.subspace.kernel.org; spf=none smtp.mailfrom=infradead.org Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=infradead.org header.i=@infradead.org header.b="KBdxftb+" 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=7WoZ2cyGDEh4C+rPTk20iaEyGOoLnozfqobsmxrDxEA=; b=KBdxftb+8CA/+k7KI5B/ScG2FL 8ZvUhLI8xh1fqvDOdwK7pqbj7GlR8B0Epltbqi/c8aHTTUdjjYvFO1IjvIz6lMv7ZuED+UYQINCDu 0MQdSnPS1GR3HJoJKoEAqGsxqXAGvYPovq9sV775oqHUxcE3U2bvfpC0ji6vcJeZvD0XvkjpXLilN yhVAgOzUf2dBZiAXSZSqzgjzyS+G4b1UXYiJys28F80FUehltLcRfxN7xUwVwPlNY0BIkaFppmKjs dEiVT6To83P6+jogDRT/MRw47QYIngN/6Fvc2IfBzCc+jHJD8doYNZFYylfiMHC/js3Iu60jiFQX2 aCNpCStg==; Received: from willy by casper.infradead.org with local (Exim 4.99.1 #2 (Red Hat Linux)) id 1wRhZU-00000000WP9-2Sjw; Tue, 26 May 2026 02:31:08 +0000 Date: Tue, 26 May 2026 03:31:08 +0100 From: Matthew Wilcox To: Jaegeuk Kim Cc: Christoph Hellwig , Theodore Tso , linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, linux-f2fs-devel@lists.sourceforge.net, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Akilesh Kailash , Christian Brauner Subject: Re: [f2fs-dev] [PATCH v2] f2fs: another way to set large folio by remembering inode number Message-ID: References: <20260521155748.GA79343@macsyma-wired.lan> Precedence: bulk X-Mailing-List: linux-api@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: On Tue, May 26, 2026 at 01:21:33AM +0000, Jaegeuk Kim wrote: > On 05/24, Christoph Hellwig wrote: > > On Fri, May 22, 2026 at 02:04:59PM +0000, Jaegeuk Kim wrote: > > > This was a quick buddyinfo right after booting the device. > > > > > > Before: > > > Node 0, zone Normal 22684 42284 28704 16901 9515 4566 1854 673 181 36 758 > > > > > > After disabling EROFS large folio: > > > Node 0, zone Normal 8486 4732 2175 1161 697 272 82 19 3 1 856 > > > > And what are you trying to say us with that? > > This means, high-order pages were used up by EROFS which sets large folio by > default. So, I wanted to say the concern was based on actual data which was what > Mattew asked. This isn't that though. What you actually need is to show that high order allocations are _failing_. The MM is far more complicated than you seem to understand. There isn't a fixed number of large folios available; when we try to allocate memory, we do reclaim. And if there's large folios on the LRU list, you'll get them. If what you want is large folios readily available, then what you want is large folios used _everywhere_ because then they're easy to get! If there's small folios in use, you need to reclaim a lot of memory in order to reassemble large folios (it's the birthday paradox, similar to the hash collision problem).