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 213D2C47258 for ; Sun, 28 Jan 2024 22:02:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 3444E6B0071; Sun, 28 Jan 2024 17:02:55 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 2F3846B0072; Sun, 28 Jan 2024 17:02:55 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 1E2976B0074; Sun, 28 Jan 2024 17:02:55 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0011.hostedemail.com [216.40.44.11]) by kanga.kvack.org (Postfix) with ESMTP id 0EE806B0071 for ; Sun, 28 Jan 2024 17:02:55 -0500 (EST) Received: from smtpin03.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 850A980168 for ; Sun, 28 Jan 2024 22:02:54 +0000 (UTC) X-FDA: 81730095468.03.6FB53CB Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf03.hostedemail.com (Postfix) with ESMTP id 766692000C for ; Sun, 28 Jan 2024 22:02:52 +0000 (UTC) Authentication-Results: imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=X1k8QQ5p; dmarc=none; spf=none (imf03.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1706479373; a=rsa-sha256; cv=none; b=4TMkr8jSdaSFJ5B4tJpIoNYmlG4VkXHOkNhZ2QMjf5MNMyTKI0HeUL0kjqQwUObgX1mcmQ yMGUemRl9iLeIARddOK5GWiu4dhisFOytvM3+jVHQMuladhPa3svloswO/cuCJlZGLLpzZ 6onTXOOmtoKFA9fBKiiKPLzAUwyncOA= ARC-Authentication-Results: i=1; imf03.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=X1k8QQ5p; dmarc=none; spf=none (imf03.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1706479373; 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=y7owlhmhi2gAoXU/UeiIuxV6mq5IG8XVGr21uGp5/40=; b=FJelrsfp/DhaiomFCNpxyxvWmA1i+YBl4/JboTm5b3Rx28dxNauAmIEDF2WphG4O8eeqps 52IzmTwH/Uo3B4PTXCfBZaUaRl9EAXLfdTmRq/aPTzoBGGr0ar7pnbRCp6MG+LiWxAZHH8 uCb4jVWvUdwMtnC2HZuUCEEup1Ggbhc= 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=y7owlhmhi2gAoXU/UeiIuxV6mq5IG8XVGr21uGp5/40=; b=X1k8QQ5pXWWbzG7O67QZFKgivf fC4g/yiD/pw9sbIud887+AHkhsj549Vtg9KNot/nBjV/HBtKG7yyvZKb4qzLdYyBXeX1FVqwTzk5+ OLVa4cfZYnxTiitLTIbnFTGWY5XD23C/3DYNAvZcKrbGDzeSypq9QHkgVFmnIaRz/WlR9AjqzBpwO JnwOEI14KUxGFsDAfQpYKajyh/iBrk6vy5fMzpPgSAMsohdV4ZgxYgd7RCPoxjUZf8Q9uetdVPZw0 Awbmxv1kdTiw9EuDqww/jOSeysk0rC+is0rNAaqXlEbxxaSqAczD9GbtHGIz9RORFmZWehVOoB2TE +MRe/u2w==; Received: from willy by casper.infradead.org with local (Exim 4.97.1 #2 (Red Hat Linux)) id 1rUDEn-00000004g71-0xeS; Sun, 28 Jan 2024 22:02:49 +0000 Date: Sun, 28 Jan 2024 22:02:49 +0000 From: Matthew Wilcox To: Ming Lei Cc: Andrew Morton , linux-fsdevel@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Mike Snitzer , Don Dutile , Raghavendra K T Subject: Re: [RFC PATCH] mm/readahead: readahead aggressively if read drops in willneed range Message-ID: References: <20240128142522.1524741-1-ming.lei@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240128142522.1524741-1-ming.lei@redhat.com> X-Rspam-User: X-Rspamd-Server: rspam06 X-Rspamd-Queue-Id: 766692000C X-Stat-Signature: dtp7ki8deheiwhx58hstqmt8bfmif67s X-HE-Tag: 1706479372-151263 X-HE-Meta: U2FsdGVkX18EjAZkhiB2Usk3lZvBYUc0PD8S2sTQ9doHCuAjZq0+VTMsgK/EWU3GtBgbaW8C8EoB8NiKFTLueb0JfFLHVSea/iHt5amaJVTKAkxgKpS2YVkXtx2I9mKdcx3Zj1XrSg6rPkiyW+BdViP8AYoxmZ7QKJJdPkfCpTrCO8azQKIQ0F6RmiA/PcBPnu1QR4lF+mT0jkUpkf5qTH9jO9s5tek0tMogkg8Ck0MWg2lVtgX85Zyy6IWz7TPlu5L11oC9RrQYF3hYsyEiBWgJf5w1/ooJVyaY6NTLAAhs1LzetZqiddbq28pwqE6zDqeBdHXK9Yyk5iz9JtATdDQMDAKvkxuVLyQR/Bxeh6RuXtVc61hnIK67OtlcTZz+5GS8eX9aD+4sc0gVHjHjVd4+BHqO9LiPzTXNW1uTsNanFR1XjRiNMiIrgbmoboCu67U02NHUNbX+JSOl4Ku3+xGaHq2AjkjyDZrSEAESIRxidSp31i6PTpfasVZMBKxnaGXOCjbTCQmuLjZe3bTQ91UjLnLv/g7szGkAn1jFCD2b5NtWVnVPLQhaT4eH6mlnS90/JDiT24XaO820vsf6QcfXyLS/6LJ6YI+VWrYnP+66aD/ht9lFEZFG/axkOHQIVo8GgZNZcvEkUS7VFqgdwie+/yqordgFLrenHnwGmJwte+/bDICbLP1zMAoFx3RMDd9lZw1j6gc94CziREedISyR1yLx8+z4SACs+PLVj9j0Z4+fXTtksLLi7xAbAATJ3QtW/J3TPgdywpd8zM4/P2RYd3BjzrvAcUEDVgZAbEDdLsu9dSL9flFw6xmt8eoTJRh0dfNe8EEGeiAOma4AM0f2wfIzgSs6pOD1kOs/BRpDP21ailj4n8kY8E0Py8YiCKvyr49egJUHVkrY1YEJiPBKjInbE712n2w6FfoJf+BTBrWirvpC0L4HYojWeqDez0qBDIp0yaRafIIsVx7 wgi/9aL1 GwRYKp185jW05JLefiwCagAVwKzzs5/Iotfx+bc/jHriBkOnPyZKkf+E+an9RAKZfwwoECJt06o3/NxS/2IiPYTYq895Ag33c41jO3Ez6BpzvpiIuZBBUb8sYE/lvYycle91VLiiSB1lZ/wA= 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 Sun, Jan 28, 2024 at 10:25:22PM +0800, Ming Lei wrote: > Since commit 6d2be915e589 ("mm/readahead.c: fix readahead failure for > memoryless NUMA nodes and limit readahead max_pages"), ADV_WILLNEED > only tries to readahead 512 pages, and the remained part in the advised > range fallback on normal readahead. Does the MAINTAINERS file mean nothing any more? > If bdi->ra_pages is set as small, readahead will perform not efficient > enough. Increasing read ahead may not be an option since workload may > have mixed random and sequential I/O. I thik there needs to be a lot more explanation than this about what's going on before we jump to "And therefore this patch is the right answer". > @@ -972,6 +974,7 @@ struct file_ra_state { > unsigned int ra_pages; > unsigned int mmap_miss; > loff_t prev_pos; > + struct maple_tree *need_mt; No. Embed the struct maple tree. Don't allocate it. What made you think this was the right approach?