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 BE191C3ABC3 for ; Tue, 13 May 2025 12:33:25 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A15A18D0002; Tue, 13 May 2025 08:33:24 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 99C348D0001; Tue, 13 May 2025 08:33:24 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 866098D0002; Tue, 13 May 2025 08:33:24 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id 63AE68D0001 for ; Tue, 13 May 2025 08:33:24 -0400 (EDT) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 5EDD31209AF for ; Tue, 13 May 2025 12:33:24 +0000 (UTC) X-FDA: 83437825128.14.D34CB51 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by imf28.hostedemail.com (Postfix) with ESMTP id 6C0F3C000F for ; Tue, 13 May 2025 12:33:22 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1747139602; 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:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=ANoKV/LAVfoHgJTa0rc6msgHc3vSusd6KvN8kOIQie4=; b=RMNUJYXl1I3LpU/NvHpX8Ij6ogzYEOI7waMeYu50BQfZQ/ur3LzIJzRosf0IafTKaJ3liF ShveP2kjfojUGlDCX2B1r9PwQoAh0dVg3At/M7my6SOqatic1u0NZFCehIrkEHXdDjh8OU 6jDVsYSL0ajCE0WRJcYi8p8/wgE8w7w= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=none; spf=pass (imf28.hostedemail.com: domain of ryan.roberts@arm.com designates 217.140.110.172 as permitted sender) smtp.mailfrom=ryan.roberts@arm.com; dmarc=pass (policy=none) header.from=arm.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1747139602; a=rsa-sha256; cv=none; b=xcNDHlIxlpgNfGrZQDj26laZMby+EWCJw40vsI3lDmQ+RRRTFia4t5vQP4gD8TuB4lZfMK sy6CQOLLRIjymB1J5VN4JGg28DM2YAs5IaxZOk2HtZ3e9frwklmi5e2W3ShcSb0Zh4pqtf 1Ur/JZQaF/loy9Rbdjzn9q3QjJIIio8= Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 721171688; Tue, 13 May 2025 05:33:10 -0700 (PDT) Received: from [10.1.25.187] (XHFQ2J9959.cambridge.arm.com [10.1.25.187]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 5EB513F5A1; Tue, 13 May 2025 05:33:19 -0700 (PDT) Message-ID: Date: Tue, 13 May 2025 13:33:18 +0100 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [RFC PATCH v4 1/5] mm/readahead: Honour new_order in page_cache_ra_order() Content-Language: en-GB To: "Pankaj Raghav (Samsung)" Cc: Andrew Morton , "Matthew Wilcox (Oracle)" , Alexander Viro , Christian Brauner , Jan Kara , David Hildenbrand , Dave Chinner , Catalin Marinas , Will Deacon , Kalesh Singh , Zi Yan , linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, p.raghav@samsung.com References: <20250430145920.3748738-1-ryan.roberts@arm.com> <20250430145920.3748738-2-ryan.roberts@arm.com> <22e4167a-6ed0-4bda-86b8-a11c984f0a71@arm.com> From: Ryan Roberts In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Rspam-User: X-Rspamd-Queue-Id: 6C0F3C000F X-Rspamd-Server: rspam09 X-Stat-Signature: na59z36ys6pg7xt3eb65ppupauyq5cs3 X-HE-Tag: 1747139602-497106 X-HE-Meta: U2FsdGVkX19spkLASHsGMsPU0gvgOTL6uziM30T8a22bl4Z8fB3MMvZr01gcgD+2H87JGRWrNNHxUznsZTee+HL7/+li1+BgQOWKhg7f4Dx6Kx5clKEACJJZVRFRBArz0hUpKlkB6noZhYSj8Qa4KZE/lvjvc9HFaXEhNz1xoEdmJwL58BNvjKOo7MFqXgM/liMHpyUIBaAgQSR3xoHOHE/rP9PUV7Z60Aic0id03WYyDrn+Qe1DVXjZr01d50ixGHvdOPsEME05TZWa4kkf0mbAvxXDI7QDdfNGmVZ1N+BAyu974/N79GsK2EIM2RvEFdmVBYspWBCq0X67zaURiOkZAF2/TjVpm+OfrsYELMZtJO92xX2i8ATUVodfxpUKFqskOCG83AfAjmiLnCsHMz+ed9nwywVN7EUbJuA2l/yB5xH2hj7V/nnOWcrP/0a47V7qRyKIQjjZC317ULILJuEZnidu74jHzn5X2/gYVdHQi62e3YMjWBSJl57cH8J5EsI6myOx1EiGQNCCdr4lLirgxiK+bYvzJoTjwEn92VGL9iB54vid1z4adgr4NwB/FYHEqCY541QwAT0hGmPAvS17GQKTRMtFpnONx6sofkWhTx+Q6PR7LdEgoFEvPIq22pCmsD0j/91lrzyiU8gd5vVJKTBj8c3kkfIQoHjGhly/YSQqiq9e+UgR7cVUMzzPwEwe7hJn9OAwFWq2xTUq017rW1mHZYpJ7SVx6cJK6NUzZ4h/n8v0WiNsaP3Z7f+PJTqB4Ece6xC+p2S1grLNDddrCt7O6qwWpRf3S87LGnz39u6hjR31QuUtRjJ8adMQh7U6MzeR+d7UCweix7AxYmMeS1yntIa7YaFCsCwgDc1tFsBo58QR2LtGgyb3L79jdUxezWbBLcsadcGeiSVPTgXGPy26wqmUqswUhvlkFg9pSekElc36TW78XSeZzRfB1+kPqbPXhTao/gmfyPD gAoAzffG 64JBWyDbZJymPrS9UfGd0OcDKgx3PJJ+PkQtGxP26v5GlxLk4a8TWTFVD0urxwLYiTZtn8umROryyjzed1pY0iNWKOLwoU6Mqpvz/zZpQ99fwVbKbvqZz9KV6OX5BmgOaRV1rg7mPHLheNGvIUIyI3rp6LP2/LRnW4hvfkyYu1nhYDmBKM6zscE2HuADsILD/Rp9Tpc8XshEvn4pcLQ4tIgPLhPdCbmF/qVCDRs+OfiJwIy0jBeKaFpOR5HbAN0ru4hKgEOIz690ZSsA= 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: List-Subscribe: List-Unsubscribe: On 09/05/2025 21:50, Pankaj Raghav (Samsung) wrote: >>>> >>> >>> So we always had a fallback to do_page_cache_ra() if the size of the >>> readahead is less than 4 pages (16k). I think this was there because we >>> were adding `2` to the new_order: >> >> If this is the reason for the magic number 4, then it's a bug in itself IMHO. 4 >> pages is only 16K when the page size is 4K; arm64 supports other page sizes. But >> additionally, it's not just ra->size that dictates the final order of the folio; >> it also depends on alignment in the file, EOF, etc. >> > > IIRC, initially we were not able to use order-1 folios[1], so we always > did a fallback for any order < 2 using do_page_cache_ra(). I think that > is where the magic order 2 (4 pages) is coming. Please someone can > correct me if I am wrong. Ahh, I see. That might have been where it came from, but IMHO, it still didn't really belong there; just because the size is bigger than 4 pages, it doesn't mean you would never want to use order-1 folios - there are alignment considerations that can cause that. The logic in page_cache_ra_order() used to know to avoid order-1. > > But we don't have that limitation for file-backed folios anymore, so the > fallback for ra->size < 4 is probably not needed. So the only time we do > a fallback is if we don't support large folios. > >> If we remove the fallback condition completely, things will still work out. So >> unless someone can explain the reason for that condition (Matthew?), my vote >> would be to remove it entirely. > > I am actually fine with removing the first part of this fallback condition. > But as I said, we still need to do a fallback if we don't support large folios. Yep agreed. I'll make this change in the next version. > > -- > Pankaj > > [1] https://lore.kernel.org/all/ZH0GvxAdw1RO2Shr@casper.infradead.org/