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 98B15C3ABBC for ; Fri, 9 May 2025 20:50:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A4CB48E000D; Fri, 9 May 2025 16:50:46 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 9FAD28E0002; Fri, 9 May 2025 16:50:46 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 912048E000D; Fri, 9 May 2025 16:50:46 -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 6F8D68E0002 for ; Fri, 9 May 2025 16:50:46 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id 2B74BBBEDF for ; Fri, 9 May 2025 20:50:48 +0000 (UTC) X-FDA: 83424563376.08.F0B147A Received: from mout-p-202.mailbox.org (mout-p-202.mailbox.org [80.241.56.172]) by imf08.hostedemail.com (Postfix) with ESMTP id EAF5D160004 for ; Fri, 9 May 2025 20:50:45 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=rG01sxaH; spf=pass (imf08.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.172 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com; dmarc=pass (policy=quarantine) header.from=pankajraghav.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1746823846; 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=4SdXRG7RMOcGcSkcOmgddaIl70trvrvcQZYo0G1lX58=; b=Uh8eZ6SXJVnAhA/lgwd/olXYm+t6DZy3yyUUThP+UV+uakREJSvRSKy9iAVK56ViovPOgK hjx+as/rSf1g7vxSSWADYav8I7Z8m6I2Sqm/2jYKk00yhvMyP+b++ioxI2Qp9gqMDCC4u7 ub438p98ve3Vo+W8iSVb9Tepwy8N6X0= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=pankajraghav.com header.s=MBO0001 header.b=rG01sxaH; spf=pass (imf08.hostedemail.com: domain of kernel@pankajraghav.com designates 80.241.56.172 as permitted sender) smtp.mailfrom=kernel@pankajraghav.com; dmarc=pass (policy=quarantine) header.from=pankajraghav.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1746823846; a=rsa-sha256; cv=none; b=5FtE/Gydh8qEYD3ekkHriJbaKZVhtynSUGcoiOqfw1Xl2XKjByAHX8/ohR51ki2nDQFtgO oz6Tdir7W8Acxxg8Ceeg4Z5eEM80vbT1qP5OCS1RQ3TC0KU2ToP/UljnuejYeL06GJlP7r 8PP9iWbnyZE3u0HBtakxkqSpC0JJiR8= Received: from smtp2.mailbox.org (smtp2.mailbox.org [IPv6:2001:67c:2050:b231:465::2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-202.mailbox.org (Postfix) with ESMTPS id 4ZvLk912xRz9spL; Fri, 9 May 2025 22:50:41 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pankajraghav.com; s=MBO0001; t=1746823841; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=4SdXRG7RMOcGcSkcOmgddaIl70trvrvcQZYo0G1lX58=; b=rG01sxaH+rCqVLlhWdLqiLaZzCT3l3yOBNy9rMw3G/0e1HhACjPeme2+mhhdloKhy+yuPn CFI5bkUTjkTrzGmxXiDFAwhv/cC3o/YsBKE1J9W0EgRrldxPShQvMfl4oNZz2vf4Bk0CCL 4FYRofVykvh3SEKvljDUkRzmZZev29V7ravpCcR6IkdqEDBu0j7OeM+855TxVCUsoYQPCn C0x1FC/xU9/ZuRkDONc6t16fVmRc8ULeFSYHoWDUTjbwMIskQLbiIOu3ZNipzqx/+d/ME+ iy7boEy+3xpOVC7yyYAuM94+4xBVMjHzLDXDk88D3GykyIAXUNobJT2z1NuSDw== Date: Fri, 9 May 2025 22:50:32 +0200 From: "Pankaj Raghav (Samsung)" To: Ryan Roberts 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 Subject: Re: [RFC PATCH v4 1/5] mm/readahead: Honour new_order in page_cache_ra_order() Message-ID: References: <20250430145920.3748738-1-ryan.roberts@arm.com> <20250430145920.3748738-2-ryan.roberts@arm.com> <22e4167a-6ed0-4bda-86b8-a11c984f0a71@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <22e4167a-6ed0-4bda-86b8-a11c984f0a71@arm.com> X-Stat-Signature: espmwi8o6rfxz989ctoqwfr7suw6tang X-Rspamd-Server: rspam01 X-Rspamd-Queue-Id: EAF5D160004 X-Rspam-User: X-HE-Tag: 1746823845-441081 X-HE-Meta: U2FsdGVkX19QMse8lf3SwXrYIVoezsmA8pQdHabwJ+2tW+RDznK213mCca/B0FIBpTUDPYDqgWMwzgCl9hwf8ecnJizsGXvA21eoMPS1VjpifuaQqVg8ZFKLaN73UwkvTg8LzyfL5FhiiOfV1pBs9mFz/Nl9pWd5l2eSYYJcJfTU4MeCWFNed1BFZj012vEEiydfZoR1hLiLpoDaRzHPxOvFNiCf7ZDs0AUY/bOVCVsIba2qHD7H+s6qnqDSsQdIvZLWXp4q71AV5MgFrfNKGrJNieqhjly8Ex3seJZD9rHDt1eHFzwOoedsTQ6fQLTfhXwkvJIkVESgtCcRcrPXRr/E5FWkdxckFMH2o7XA74wNYxq2QdAX1LC43DwVNymeIdxp6yYYfKaWW8uixAuJ+GVmknw5qVdTfrUEIgbXIWHOD6PDmBL7YW6p4fgqDr+wuPIURsBpcvrX4ypbSToLUOx9qqksPiQqy1BuSzVZbguYRsJ/o+V+QfxAaFmnMtIvqDinSwpNulNaDT6o+L8cVt1Np3qgRjl+rZ1fz6cVJ3xkkjyGUYbtLWsMfC0QcCoBotBo+TJIkgA0e/2AugqU+ItEX/f/ZwiywJq9S0QzstFAVLNDJVyps4GUA5uw4o+CZ0pqBPE9OG4eYl4sALI6KNH5JKx0sVK3pqWgN6pkyastsavU9kFPuawp/wjhJCwYkpdXV+kyP6k1YVxkRzVHWSsXCIf9ycbkBe+UWAJh2OTkpNbNgJq/hUXuYBtgzHPb/FFn1V78tkwHkcsx3UcfJUJO8w/AxSDiXPLpQNKV/rljEnRKB5Ic3mqmGFSn3UkoNXVKsYOttUTfyc4NHaeG1H14b2m6JItJZz/ERjBiVVRQ+XhGz7A1h/+/QmXElri5jfPO/rdfhQZJ76iyiG+guuPm22bFl8g9FZg7X2utWO5cj0ErXuAIt77DirJajaLGMo0pegKKecUEUHU0Lph fP3MY/o7 ahsHcjY4bnjbXbtXKxdAxnYtpIApFSU/MlQcj0gt0QIytkNDdJESuy98NncHW7pdovaS+O17iLD7XGAkHv9jII4PCP0LsOFaTflfbe/iLqwkSkMNnX8I4qlCU+UjsxM9nk5dXLfdeGOcbRjB6N4x+2/cet6E6ns0BMkcv2287ZfjmBq9UnAcK8dnvvysHAwGs/0XCoDzI5XUv0JSssW5tQeNeM3GAPLQNF0Pl7sC/hFT4bFQAfg7gw9uSgyGF6A0Z+zpjttXf5fpmxqwRMgGYJ6fFtPgyHx4I69f1uTXVARFL+2FQhHU5MQoatAywuAI+MLtgfFNK12Rd3baBdcnpQI52rhrtuikLpc97NRjlDqC00aU= 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: > >> > > > > 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. 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. -- Pankaj [1] https://lore.kernel.org/all/ZH0GvxAdw1RO2Shr@casper.infradead.org/