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 ED49CC433F5 for ; Tue, 10 May 2022 22:18:13 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1AA246B0071; Tue, 10 May 2022 18:18:13 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 158916B0072; Tue, 10 May 2022 18:18:13 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 048766B0073; Tue, 10 May 2022 18:18:13 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id ED4726B0071 for ; Tue, 10 May 2022 18:18:12 -0400 (EDT) Received: from smtpin18.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id B9EF181AF7 for ; Tue, 10 May 2022 22:18:12 +0000 (UTC) X-FDA: 79451247624.18.C06E387 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf23.hostedemail.com (Postfix) with ESMTP id D7AA114009A for ; Tue, 10 May 2022 22:17:58 +0000 (UTC) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 56D24617F5; Tue, 10 May 2022 22:18:11 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 74233C385CF; Tue, 10 May 2022 22:18:10 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1652221090; bh=5yEe4D44yUcfWHEZ8mIUjXGZ6LTehhn7/6meohWTYp4=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=Rm8JynhWQdxAmeoI0WkmtXG1QNxG4cuL2/vIn+x1LxmBF3ufyf0LFXFOWBRI9L3uO rnyUOj4dhix0PZd9dbGOBOBhAD9Bc3qRd3qdHsj52ReSlpMMYI2nPXGkotEPgSB+pD MSAT3KDZfF5uisxgWY5s1VMErPW9oDmGBQ5A0hWM= Date: Tue, 10 May 2022 15:18:09 -0700 From: Andrew Morton To: Matthew Wilcox Cc: Linus Torvalds , linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [GIT PULL] Two folio fixes for 5.18 Message-Id: <20220510151809.f06c7580af34221c16003264@linux-foundation.org> In-Reply-To: References: X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.33; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspamd-Server: rspam02 X-Rspamd-Queue-Id: D7AA114009A X-Stat-Signature: fs9eqa3b7b8jwei1jpsm6y6ks5c3yknk X-Rspam-User: Authentication-Results: imf23.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=Rm8JynhW; spf=pass (imf23.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none X-HE-Tag: 1652221078-769961 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 Fri, 6 May 2022 00:43:18 +0100 Matthew Wilcox wrote: > - Fix readahead creating single-page folios instead of the intended > large folios when doing reads that are not a power of two in size. I worry about the idea of using hugepages in readahead. We're increasing the load on the hugepage allocator, which is already groaning under the load. The obvious risk is that handing out hugepages to a low-value consumer (copying around pagecache which is only ever accessed via the direct map) will deny their availability to high-value consumers (that compute-intensive task against a large dataset). Has testing and instrumentation been used to demonstrate that this is not actually going to be a problem, or are we at risk of getting unhappy reports?