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]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 68503C55ABA for ; Wed, 5 Aug 2026 13:51:24 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 51A2D6B007B; Wed, 5 Aug 2026 09:51:23 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 4F2026B0088; Wed, 5 Aug 2026 09:51:23 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3B9DD6B008A; Wed, 5 Aug 2026 09:51:23 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 022E36B007B for ; Wed, 5 Aug 2026 09:51:22 -0400 (EDT) Received: from smtpin27.hostedemail.com (lb01a-stub [10.200.18.249]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 8EEB7C043C for ; Wed, 5 Aug 2026 13:51:22 +0000 (UTC) X-FDA: 85067352804.27.2F7F81B Received: from CH5PR02CU005.outbound.protection.outlook.com (mail-northcentralusazon11012062.outbound.protection.outlook.com [40.107.200.62]) by imf04.hostedemail.com (Postfix) with ESMTP id BAD2940009 for ; Wed, 5 Aug 2026 13:51:19 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=Ma+sJDkp; spf=pass (imf04.hostedemail.com: domain of ziy@nvidia.com designates 40.107.200.62 as permitted sender) smtp.mailfrom=ziy@nvidia.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); dmarc=pass (policy=reject) header.from=nvidia.com ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1785937879; 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=Nz2Re53Ace72dDj82JFm4uiEJHQKAUBPQr1ZKu/TRxA=; b=UaTmhnRTU7mlAuXV3Vns2OVFI+hH8CzqVTCgSTEmpDb2fIIV08a8usK8oS6LJ90383EOMA PmQ7HRmXrSjC1rAIyKqoEAfH/wOdVtmJaWZx4YQ+zpfEr1I93ODO44Nqmfh11mTYt2CSzQ i8LL2+Rb5uvfAL+ZDu8yOat8IoLPC90= ARC-Authentication-Results: i=2; imf04.hostedemail.com; dkim=pass header.d=Nvidia.com header.s=selector2 header.b=Ma+sJDkp; spf=pass (imf04.hostedemail.com: domain of ziy@nvidia.com designates 40.107.200.62 as permitted sender) smtp.mailfrom=ziy@nvidia.com; arc=pass ("microsoft.com:s=arcselector10001:i=1"); dmarc=pass (policy=reject) header.from=nvidia.com ARC-Seal: i=2; a=rsa-sha256; d=hostedemail.com; s=arc-20220608; cv=pass; t=1785937879; b=ldecX8n0UvwR4Glnj9bXZJ2olC1EzdXhkui6vHHoAW0G3naOBxtAOjRAD3x+z8iF70Vuz+ FerBtrXC+4ma0ZaqWZOZs9FFi6tVwaSdc9oRo+LU8l5euNM2B07oL9svFBb0Ked3B7NwPm R/cqP1JEljHuI8rPJNVVAaEY0fWorQc= ARC-Seal: i=1; a=rsa-sha256; s=arcselector10001; d=microsoft.com; cv=none; b=pxcY2oe0URBFIcWGURtnHS9hpSB4q8VoT4TqVrG6zd5ZlnYBduSX/lultsYI3I6hs1xS6NoXq0U8FFbiCokNMwAlD38IPYBWqlW+aIduU8SUG8HUq2bZc2XkQuvHza7/xXkFgUObc6IbXXnE0hn7EuaU3KmdQFjLwsAtW8O8oNqGMEeY+qT4vLV8amK2gMb4y1ijDJUojfiniM6OYaLFA4cf6bRL5njRyydec5LFgIrJIGSlyLyigQRo060Li0ol5qx9PCVufZA2spKfOG75M8l4ZrKvKGgsTZS4pQoeFf1+5jTKMVsbelg9iUzhYy5oNztW1uUnG1/so2MwhhgjHQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector10001; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=Nz2Re53Ace72dDj82JFm4uiEJHQKAUBPQr1ZKu/TRxA=; b=RFNEwlOQiPG5vJVVJDrGVH0hbnEc8LmNkYkCB2ljVzLuLaEqWwGqu676hWHPPJT+jZuKH1BS5X8JyJrqiOWkWRMPk8ud2i+EfCLC8zHqixaqMgjQ6HehmpAGz0gfIVGwnScRzmdfKyvBaEqyuOicnNgIA61QmcrV5r0x9TCJp8+7VtWog6pij2Pn4SYY3/dd4GcV/kFfJQis8RqUlblxC+Vz6WLJGFeEHM18ezRQUIt/qD30jZzIWV556WNBfjQEYNw4HjNCg6ikS42OOLt5ILNAIlyGKSX/aytUMT/PRAi1pRbHQEFryPbJH1COC7ydhZgEMeJOzAPWmPIFinKIhg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=nvidia.com; dmarc=pass action=none header.from=nvidia.com; dkim=pass header.d=nvidia.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=Nvidia.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Nz2Re53Ace72dDj82JFm4uiEJHQKAUBPQr1ZKu/TRxA=; b=Ma+sJDkp7Msz7r8HWsJOFou74uawbE2e62y6ktUJfnF7RGYKAeQMSvpTd8AzX3uMOeK/AoZ4XpzGS1XGZSesckAPjfTIko85p6F981en0qQQHpNGck/mx4wxPWi0fNv/xFQ+yhipZtQo3ZsAKLTNN8V9aXVXwYohy652SSrmDvBlNOjgoj1e+ghJuMF5x4PKnZnKKpj1nPhHqVzkRjSLtW11KW0k5kB+ohh2iejVINlvwfsO+zTmbY1MhT2JzFkJMIHFJCnFggvlSgVkTu7VHFsW/GGLQYCZiqSAtscKfvngIPz3Wf457jhMRa2yB3HgXB39yua70jK10DDnyZKF3Q== Received: from IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) by PH0PR12MB7958.namprd12.prod.outlook.com (2603:10b6:510:285::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.21.292.19; Wed, 5 Aug 2026 13:51:09 +0000 Received: from IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16]) by IA0PR12MB8374.namprd12.prod.outlook.com ([fe80::d85f:4c87:ae84:3f16%5]) with mapi id 15.21.0292.018; Wed, 5 Aug 2026 13:51:08 +0000 From: Zi Yan To: Jan Kara Cc: David Hildenbrand , "Matthew Wilcox (Oracle)" , Andrew Morton , Muchun Song , Lorenzo Stoakes , "Liam R. Howlett" , Vlastimil Babka , Mike Rapoport , Suren Baghdasaryan , Michal Hocko , Baolin Wang , Nico Pache , Ryan Roberts , Dev Jain , Barry Song , Lance Yang , Usama Arif , Gregory Price , Ying Huang , Alistair Popple , Johannes Weiner , Qi Zheng , Shakeel Butt , Kairui Song , , , Gao Xiang , Chao Yu , Yue Hu , Jeffle Xu , Sandeep Dhavale , Hongbo Li , Chunhai Guo , , Subject: Re: [PATCH RFC 07/14] fs/erofs: mm/pagemap: add readahead_folio_reverse() to avoid folio->private Date: Wed, 05 Aug 2026 09:51:06 -0400 X-Mailer: MailMate (3.0r7024) Message-ID: <4932E65F-E4DA-4040-B673-F470002A8DB5@nvidia.com> In-Reply-To: References: <20260731-remove-pg_private-v1-0-142c97ba3562@nvidia.com> <20260731-remove-pg_private-v1-7-142c97ba3562@nvidia.com> <332rknj4vo3cfhvfhhlf6pvg37s3lbrnzbbnv4swa6gctsiu6a@ndotgokvnglc> <2evaxdu6cobpnzzer3y7fsrqvmtmhj7gm3e5buebdaw564igx6@7bs5enipxnpx> Content-Type: text/plain X-MS-Reactions: disallow X-ClientProxiedBy: MN0P222CA0022.NAMP222.PROD.OUTLOOK.COM (2603:10b6:208:531::29) To IA0PR12MB8374.namprd12.prod.outlook.com (2603:10b6:208:40e::7) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: IA0PR12MB8374:EE_|PH0PR12MB7958:EE_ X-MS-Office365-Filtering-Correlation-Id: c84537fd-08e5-4985-438a-08def2f89a34 X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0;ARA:13230040|1800799024|376014|23010399003|7416014|366016|6133799003|22082099003|18002099003|5023799004|11063799006|56012099006|10067099003|4143699003; X-Microsoft-Antispam-Message-Info: 5pjnZmImJfRXWXvF2cr1QLwqUH6nM8d7EP/wvRzqDkro/j18z4cmb/+04+Wr8YyEKX3MTLOR/+4hHZgwEfJc85yEGgC6EhYCW7KobGBZUaff6EkuHCsvY45zcgdXOBbJtyWFIciMdF5hdrMsEhHdiHIai75riie5TCDaslcKQzxA5AXbZqrKIn1KTJgXmtf14cJTIUx2/jBowku1TtkM//frNYeREfnXzXmdXPLlkuE0IEzEfN9THSqU0gHjgIX+imbRbuxbWuNi4o054+K4n0FNrKDZ1Cg4E4H5gfXarBQBHImCa0vAYcBvYJsz0eiN3CtHmxncKTDNHFX4nKdwail2u5TZvZEYtE/yoqansMB7ASXSlrbAYe2aRElyzvFhiM1Aco9rzD0C5bFkKRIbNflZ08zkQub56pSdiER8mQi+JWqgXqWVSARQpIypFEaKqFi/gdPqjvMcVTZNWghW6f0VIbqKboDKQamh2h6L89Pfsd0MDOPrmDdHMG2D6FcNF+3yuf2g2TIPdlrq0uUrz3wioYW+Der1C2KWDN/q8ZvixX9fEcftTN3hTbbfizDEyifuE8HRFr8AdVBVYgsI2A79XAVbe8Avbv9Cs4oJ46/mR508rOj9Y50fUS6eDVUU4VzUEYQ0ELN+IO6hmiQA3hcynYjCjB9uZEM45luiCSA= X-Forefront-Antispam-Report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:IA0PR12MB8374.namprd12.prod.outlook.com;PTR:;CAT:NONE;SFS:(13230040)(1800799024)(376014)(23010399003)(7416014)(366016)(6133799003)(22082099003)(18002099003)(5023799004)(11063799006)(56012099006)(10067099003)(4143699003);DIR:OUT;SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?CNnuixnr9cG6Sf9ppwtGeN6b+dR8+Qh62mZ8kCNCmqMF6TzHU/1tytzCYm4r?= =?us-ascii?Q?DPWSiMHux4oYgpdREnL/gLwFTx/rikEkf6hPQ+PzP4hXK5RCmozsx+NDkF6P?= =?us-ascii?Q?ixj4+lGoGqcDdBFeSqR+v15i5AzJHBgBze/8kofxoSUUNIQHJi6DbaNEitYi?= =?us-ascii?Q?hjD1S3pQrlTinVkrWxfLtEhdoG+3Cc8nAB5PQBpnCxSXYH2uUuViVXm5KAZP?= =?us-ascii?Q?jx58uIZzDRnRpfBk6z6MG+3GwmARYX7bPgZhoTsythcx5Pst/ALpQ9p7Sjw1?= =?us-ascii?Q?XbQ4MoQjuNyG/BkQKRByOSO5BgpHCF7v94IZNiMOGj6OJ3CHuF1N3oYQgEfo?= =?us-ascii?Q?Wein+c/CoPOUqPOYSK2h6N/DrfrknkQlu65cVw/PnT6wFvj0iTZ6fsD4Yffe?= =?us-ascii?Q?BQtUDXTK8fbSWsBdCddxzd+U4hgAkNT0GkfwZluv+aPBHFbUiEpqw84JW2Hk?= =?us-ascii?Q?pC4Imu4shsB/1PJY028wS2MmEImCGV+Qq8Rv8lc4IR+uNbwVWQawo4yd7dVD?= =?us-ascii?Q?I+QwZ9XFgqma9TawnGGDivpWNo9OCmW5DQoT3xC8rpDWCG4ZjDuzNm0Gm/m8?= =?us-ascii?Q?uP9u9kYmklIaWI/+BRngm+bv6dXr/fKWdY3nBkiAW8GcZZPglrJl59VZj8EG?= =?us-ascii?Q?Pia0s8ENJaGJRzOStpI6R/3PF34E4/IuI3WfL3tzmW71E/Ep5V1nK3LQ2XSk?= =?us-ascii?Q?PCq1YeNAQp4C72chvuG/UJ0lig+U1joZmcf4w9U6S/hHZTWz/aeU9wz8bRki?= =?us-ascii?Q?HXK5au9hTlzUpqK2eBsMmRwsxxM6/Nn0jK9nJRzh59TGgyBavEuVCREk/lme?= =?us-ascii?Q?g7vsqiF5iGADBMrVC5HmpWketcjcUfwd0KKH+1l93QbE6prhQalFAf0AE+Fe?= =?us-ascii?Q?zHw8gWXdwMEVVnoakDeaCdXTVvzsYfiBa/qhh2HXuKRvvCYG7+RuDe5bw0TA?= =?us-ascii?Q?XKY54M0jQKzx7dbh1uqI4hDu23+iwW4mJNDpGb5Db2mvXncQEtGB82Cv1PH4?= =?us-ascii?Q?SC1AYuqB/M1oNWQnbU08vyt4FHRb/iTgxmqsPVO7PRv+/RT9wMinQqLW5127?= =?us-ascii?Q?DPIKoz7ejTlE1frlbGa1o+gyZhLBCmNyPd6sQvysUrfbFnfpcoXEdWSRF/38?= =?us-ascii?Q?dHBxnSpsbME+cV4dtu5wUqDbkWwCODvaO8u3YfaIvwPW2qBEm/JiwrW5yQxh?= =?us-ascii?Q?GmjOt5AYK9Gipw/5Z8v04Z3zz8jV8Bs6G9UI5e5rWwosMvBs/7I3Mhnv8fFw?= =?us-ascii?Q?xJJ50GrNSc5XWq+8um3NkHA946g3GMh/+XAEYzrZoU5DsU8Tns8rpRH7zehY?= =?us-ascii?Q?RGAbmh/ChURki/2hHkD08ImaS63aOkB7Js1zV4846u9h92etMKArHHcBtsiT?= =?us-ascii?Q?tbfFoN+QAU4Yf6iM30/ZrhB7PzevVdnCdTb/z6TWpM0UqyiREc6sJXMiB0EM?= =?us-ascii?Q?x5pIwdfIff7ZiNH+5gfBads5xkr9JG3wwjIsEvYxzmEgejsafXPoRdbEkSNM?= =?us-ascii?Q?rHIkQbE81cghsoGBRvUFtKjTGYULVXMN6+JpPzyh6bF+pc+tkVi9gznznHWq?= =?us-ascii?Q?JsgwfGaDOKl+jvgKEZk/WwCaOPKc1j4re3mBI4qpRYRxdxeKqAIagWCQyEOw?= =?us-ascii?Q?GySGXpCq5099UQzNwYZpaCyC3sQ/JJPf2bAD0vcifQzw/qsZd6y/jUC/pol7?= =?us-ascii?Q?K1Mj+uMsqeF8lzHovk3wVVf1tkXU1vJaZkw1LS8SxBBB42zSCIv6rB92ppAd?= =?us-ascii?Q?zinmoSaWYg=3D=3D?= X-OriginatorOrg: Nvidia.com X-MS-Exchange-CrossTenant-Network-Message-Id: c84537fd-08e5-4985-438a-08def2f89a34 X-MS-Exchange-CrossTenant-AuthSource: IA0PR12MB8374.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Aug 2026 13:51:08.8038 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 43083d15-7273-40c1-b7db-39efd9ccc17a X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: JBvopJ33uPwVVpgJnNot70wWd1LFSWsTlfxTOzTUA7dUFBEi5YYp7K2sTjQK7/wJ X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH0PR12MB7958 X-Stat-Signature: oum44dtsjzduzb86fq57owaotu9bppps X-Rspamd-Queue-Id: BAD2940009 X-Rspam-User: X-Rspamd-Server: rspam06 X-HE-Tag: 1785937879-398811 X-HE-Meta: U2FsdGVkX1+hayFaSx19VnEKrInmbnWtLpMDXnlh5zbPPZVItqLZd1hhx34t75ZiOIWyW4UWSIpB8ltXC9nA1brOfttA9O7okeC9wUc9Nf011mbimvFMtPq2918ckncaMzT23Q8aQAeY6SiY2GgKOlVMbV27w+a3tM5UdDYuGkPYVV7WNHAE8qOccvdzE1w1c5ACQu6z3CHM/ZtVPJLVfVWwc9SbvhkkkCawFeiYHTsEZ/0+WtpBRz3n4+q/Fu5kULJ5sbxq0dKT7DFor59oLM2GGpJfwoesN3ceCLOZ/xqcH+aIeTfHdq1NNuM9O407aIMabMJcRcKnLUHSNO1rMWj1HVGEVdmBwbiVQsobZgiuRPEXQUcrL0Sw8bC4bHlvT//XU/ib+baJRkwZMy9ww+y6rQhLNpBxK1KUp0TPVRRxC70OvrDIsDyTN1whdLOliA93VmcAJgTKCe6CJ0QIosB7YfwSsRQSr/H8B8nnSeNN2IFef7eyq3ZHDzRzx3ehrK11iKiTt8iZZsshzlKYB5ujVnsOu0T0UGmtz7UtQ3sk5nwUBVFTvUuzrKjZu7ZQaSSN9zg7U3y1GkaldZwXk1+e0nfnZh6utdRt00FEFd6W/ngRwrGjZ8mqdc6MJZmridKqtTtY2AYw1J2NVg3USZmbHVkvJRtqjManem3kYiHOg+NohP16KSTvXTK6P/DE+5FxmT6SJRNE1FsOnAxKrdBiee8Cf8fteITfSEDbpuGTCDcEg1cv8HRRmJ/H+OKeyrdbdgdPLX/BDefXrAhro4h6mbD0vfF1s7y9X2CS4dnos/omzVWNS0m7jrSD19AgbvYOkP9sSkIZNITZuEXTnOvs/uQLSu3rwfYA0kwNgJ5gbpeK7Dhfl/VMNQ1i50BoAUEsRWvuz1gOuunbSYv6rbJkG96YuDDhXtndbKGo6+Z3gT/ri4+riYEYsFhSTvXP0s9JD7av1GLz+K5HAmf ZzL8j1I5 MXw+EExbTGmHJadN4HOdxzNuYCqPO6ioYJbmTSBh+YZsb2DKGP5yUUIsvpthhvAa//1PAslR1JoqAG/QCjvTBXHqSzYAfRpikDNPXEN/YOyACCePgpRpfCrRk7TMdQj6Pnle91j4uVpoM0DJF/7C8xdOMKw4/H1wxSBpimEYMLcQY6BNoUQe2Fyo7XdQB5f8cRfxtwJzE/dKTafu/16ePaYVu+KJ0RpBB0kpzO9RL/RV29ykJXxxDx4ZNfSEicD2BMgljmpItQdyaSosrXOxesksCKGoU6u+qB7D/3ND7oCNbrcJWRNdQ85vDWDXb9q7e4r67KkGS9+fLu9Sk7erkD6jonaO9fwxj1C80r4TtpbOzNekYC4eSwGMP/BOaGrMsDhg/SwMIzeqDbyXJREADjNd9W/Uj112jxyGC Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: List-Subscribe: List-Unsubscribe: On 5 Aug 2026, at 7:42, Zi Yan wrote: > On Wed Aug 5, 2026 at 5:25 AM EDT, Jan Kara wrote: >> On Tue 04-08-26 13:09:46, Zi Yan wrote: >>> On Tue Aug 4, 2026 at 1:04 PM EDT, Jan Kara wrote: >>>> On Tue 04-08-26 11:54:41, Zi Yan wrote: >>>>> On Tue Aug 4, 2026 at 5:32 AM EDT, Jan Kara wrote: >>>>>> On Mon 03-08-26 12:56:36, Zi Yan wrote: >>>>>>> On Mon Aug 3, 2026 at 5:54 AM EDT, Jan Kara wrote: >>>>>>>> On Fri 31-07-26 22:13:30, Zi Yan wrote: >>>>>>>>> erofs needs to traverse readahead folios in reverse order to achieve >>>>>>>>> maximum performance by >>>>>>>>> 1. reading all folios from readahead_folio(); >>>>>>>>> 2. storing the prior folio pointer in folio->private; >>>>>>>>> 3. traverse from the last folio to the first one. >>>>>>>>> >>>>>>>>> Add readahead_folio_reverse() to achieve the same function without using >>>>>>>>> folio->private. >>>>>>>>> >>>>>>>>> It prepares for a future commit that replaces PG_private checks with >>>>>>>>> !folio->private checks. After switching the checks, erofs's use of >>>>>>>>> folio->private without bumping folio refcount can cause unexpected >>>>>>>>> outcomes, e.g., in filemap_release_folio(), try_to_free_buffers() becomes >>>>>>>>> reachable. >>>>> >>>>> >>>>> >>>>>>> >>>>>>> The below is what I come up with. I did not add a bool to >>>>>>> readahead_control, since I think that is the decision of caller of >>>>>>> __readahead_advance(). But let me know if you disagree. >>>>>> >>>>>> The reason why I wanted bool in readahead_control is that if some code >>>>>> ends up mixing readahead_folio() with readahead_folio_last() things will >>>>>> get confused (because __readahead_advance() really wants to skip the batch >>>>>> returned from the *previous* call to readahead_folio[_last]()). With the >>>>>> bool in rac, even mixed use will properly advance the state of the >>>>>> readahead_control. I don't think mixed use is very realistic (at this >>>>>> point at least) so I'm ok with leaving that for later if you don't like it. >>>>> >>>>> Got it. I am trying to figure out your mental model of how the mix of >>>>> readahead_folio() and readahead_folio_last() works with the bool inside >>>>> ractl. By looking at readahead_folio_last() code, it is almost the same >>>>> as readahead_folio() with __readahead_folio() inlined >>>>> (__readahead_folio() is only used by readahead_folio(), so the inline >>>>> can happen without any issue). As a result, we can get rid of >>>>> readahead_folio_last(), add set_readahead_direction() to set the >>>>> embedded bool read_from_head, and use readahead_folio() only. This >>>>> removes redundant code in readahead_folio_last(). One thing I am not >>>>> certain is whether we want to >>>>> >>>>> 1. use set_readahead_direction() explicit and warn readahead_folio() if >>>>> read_from_head is not initialized, or >>>>> >>>>> 2. set read_from_head to true by default, so that only erofs needs to >>>>> call set_readahead_direction() to change read_from_head. >>>>> >>>>> The former is less confusing but changes how readahead_folio() works; >>>>> the latter is simpler but implicit read_from_head state might confuse >>>>> people at some point. >>>> >>>> My idea was: readahead_folio() will call __readahead_advance() and then set >>>> rac->forward = true. readahead_folio_last() will call __readahead_advance() >>>> and set rac->forward = false. __readahead_advance() advances from beginning >>>> / end based on rac->_forward value. >>> >>> Got it. I can do that. Just to be clear, it should be that >>> readahead_folio() first sets rac->forward = true, then calls >>> __readahead_advance(), since __readahead_advance() advances based on >>> rac->forward, right? readahead_folio_last() as well. >> >> No. I wrote "and then set" which means after and that is what I really >> wanted to say. You still don't seem to be understanding the logic of handling >> the _batch_count. _batch_count is the length of the returned batch. >> __readahead_advance() updates _index and _nr_pages to remove the folios >> returned in the last batch from the range. So _forward needs to contain >> whether the last returned batch was taken from the beginning or the end of >> the range and __readahead_advance() uses it to update current range >> accordingly (before we go and return the next batch). We cannot clobber >> _forward before calling __readahead_advance(). I hope things are clearer >> now. > > Got it. Sorry I made some assumption instead of asking my question, so I > misinterpret your words. My question is who sets the initial value of > _forward? So that __readahead_advance() can update _index and _nr_pages > correctly at the first time __readahead_folio() is called? > > __readahead_folio() does: > > 1. update _nr_pages and _index, > 2. return NULL if _nr_pages is 0 and set _batch_count to 0, > 3. return folio using xa_load and set _batch_count to folio_nr_pages(). > > after the change: > > 1. call __readahead_advance() to update _index, _nr_pages, and > _batch_count based on _forward, > 2. update _forward to true, since it is __readahead_folio() > 3. return NULL or folio based on _nr_pages. > > Then the first time __readahead_folio() is called, who sets _forward to > make 1 work correctly? Never mind. Codex answered this: The first-call initialization is not a problem: DEFINE_READAHEAD() zero-initializes omitted fields, and _batch_count starts as zero, so the first advance is a no-op. I will fix my patch. Thanks. Best Regards, Yan, Zi