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 4A3BDD41D4A for ; Wed, 13 Nov 2024 04:19:42 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id B95F66B00BC; Tue, 12 Nov 2024 23:19:41 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id B45CC6B00BE; Tue, 12 Nov 2024 23:19:41 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 9E6498D0003; Tue, 12 Nov 2024 23:19:41 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0017.hostedemail.com [216.40.44.17]) by kanga.kvack.org (Postfix) with ESMTP id 81DA76B00BC for ; Tue, 12 Nov 2024 23:19:41 -0500 (EST) Received: from smtpin11.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 2F5D3C0788 for ; Wed, 13 Nov 2024 04:19:41 +0000 (UTC) X-FDA: 82779767406.11.100802E Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf05.hostedemail.com (Postfix) with ESMTP id 6073E10000F for ; Wed, 13 Nov 2024 04:18:18 +0000 (UTC) Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=YUznw+NH; spf=none (imf05.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731471385; 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=kTALZnq2T1n7J//36VbyPVK6OXiR60ttmPhQ08LGmhM=; b=iNgNeJPOmqTlV+6uAd08+ZXGIO6bxe1RJSLitOdyZHkkEd2a8hwhxvqXjaz89j7qmGvDTo YS74ey0d/TyaCgmpbX9lNsW0pCWxYplPwjFYaCGwkX6+hfnN1WvnBXOTzy6r3Bgfn/Lr9s gJodsl3I2HrKuYjp2OqCDy/KfTJjyTQ= ARC-Authentication-Results: i=1; imf05.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=YUznw+NH; spf=none (imf05.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731471385; a=rsa-sha256; cv=none; b=jCALy2by6oP9m06UOkTyrVzxDSBFNC9FZ4J1Wg1zo9WcP5rufiE9hq6dGvmReKPrIR7et8 ojAZJ/wQKmse81iGc3hZz+FmeKX0HEKmwuKsBrli0QwaK3OQCb/AmW7Wl6lXAcbJdKfX5m 5DKL4IxMfxrazoNq0YcS3RjwqO5EDTs= 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=kTALZnq2T1n7J//36VbyPVK6OXiR60ttmPhQ08LGmhM=; b=YUznw+NHEwKRlmPE75y+3RrIQy 7bByRM6C60hdBI2iogehPlXa5JTiHPUVCqC50TJW4yihem5iVWr3K10upl0K7Mr7N/U7JlLDeLZVx hqTB1MMShMDBD/BeG7pPlAlY3Mrn2ODsTH92lsVEBaL0Xym8wc3ONGne8YtUxiJxbiYr4KzMBAvfR T3ysHUHfAkm4jlFbrsvk0wMTdmkNFyPseirnM4h9dSe4q+4iFH3fF44H03fZ3DL9EsrFREw6SU5sP /4DYttWAlHb7i3YudQTqYSEOumKMIjhGzl4tTcBsTTkKBXeJaYfqklCfGmg+TgkEv6rcVvqg3prC9 MqmlvavA==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1tB4qu-0000000FfmP-1m5q; Wed, 13 Nov 2024 04:19:36 +0000 Date: Wed, 13 Nov 2024 04:19:36 +0000 From: Matthew Wilcox To: David Hildenbrand Cc: Yafang Shao , akpm@linux-foundation.org, linux-mm@kvack.org, stable@vger.kernel.org Subject: Re: [PATCH v2] mm/readahead: Fix large folio support in async readahead Message-ID: References: <20241108141710.9721-1-laoar.shao@gmail.com> <85cfc467-320f-4388-b027-2cbad85dfbed@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspamd-Server: rspam07 X-Rspamd-Queue-Id: 6073E10000F X-Stat-Signature: kqpgi7c1u3xtf3uhwmhywuj9wy7pogmr X-Rspam-User: X-HE-Tag: 1731471498-922554 X-HE-Meta: U2FsdGVkX1/nioxljHF46PwoUGstcZLO86SbEO2kuKX1FFktzWygjeiyodrCsXcVQx3yA0BVtA3PW72RakKprKHCGo5SFA+7AUSAU1uVYYz/T4lRBw744jZruYiVmAQgDWZra1kS2+FYKob9Q28378l9wt1Am0HdWltaLXhCJb5qELBxMITHI5cUUdTymsohKluPJHvpk/lKqXTOaZFDuYwYhCgW0MyPO3xtFXMil8XckTmk3U7zzHde47R1SHL3eH9xtsJH9QKrhZTru/nzZ8xIyuHc0f+bTGIe6EKjw8+PyPlTG5fgo8BCu8HsQsErjZ/XwagjKenMbPEHZTw/MbSri6VZcDrOTINEmvL3A4KgLkn5KYbCZJbKaIbdahoOkxJ+ZBOYKYYpA3jbyvjuEIa6ivikXaV0X731kwl6hCVLXd4AD+GAe04ww6ZUj9FnU/XxTCtZlemLgZ7FeiUjWDdqXibT0VmC3c1MFSR1uxPP/pibjZqju6nLIO7ht6IsjPg/ihkdWXecGqUqy/z48rYOg2sE5XQ9utJxoqSHkJeddzrwFdkssEo/s+LLjKiVuCfVTQPb92D/7JJ8qe3AzQEUQGZUM53EM2JHxRHHDO4Mn6keKm3nta3gsjDTVV8Ww7b3rw0a1EntgTbXHzZjlfQBNwrfW5H/TkcX0bn+kcItvGWWWMgu4+y+lXLa2i2GOGKhROAXMZhFmcAhMCyUjctt8tzkrLE4K6PlyxQ8icFBwF28Fu7i2VgOHXm+CcOZbxbCZhbdqiKZIJQ/jwTg7fcGzSOFQaNyaZOTvUfR3WNTBimQCFCVlyHq3JuAxkj8cCQDVCQ7cTE8T7A3paImvX0P//Dz+081XLcrZmmXYe75gQmDhkUt4SyrvylDqgGLXDjOU+9bTsSL3cuczRfjN2PtjQ0bCm7D1rJ5BjVsH3z3H3VFDhhcutvXN8rdFSOkurQYDB4z9dopW600FV0 b7tBjOlX WaNo9Wl7EuGqn835YEN48afXdI0lfDqpAYPe9qFcKTfoTP7gKOkAKqbCbNnYIxBPCw4vFJQntXH/QUIpuK3wGMMPFg/oIUM9sp/011y7E27opzX676GYPP7/z806Y4N6Uf+I/R8pVGnbK2BWfxAPjB2XkOKm/pv7nYjnEWB8OnNmFoOEPSFHKjf5c2PvmAcjV7vwmzqZMZRGpS0SY3rfjgCteLFYEGXUX1GvsiWNLoQpA26t+GJDjGp94r6ifUPq9MAlXYZwXvFmDB6MqxZDzSsHKWAM2hPrZmksVj/6GDQ0TFNU= 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 Tue, Nov 12, 2024 at 04:19:07PM +0100, David Hildenbrand wrote: > Someone configured: "Don't readahead more than 128KiB" Did they, though? I have nothing but contempt for the thousands of parameters that we expect sysadmins to configure. It's ridiculous and it needs to stop. So, we listen to the program that has told us "We want 2MB pages" and not to the sysadmin who hasn't changed the value of readahead from one that was originally intended for floppy discs. > "mm/filemap: Support VM_HUGEPAGE for file mappings" talks about "even if we > have no history of readahead being successful". > > So not about exceeding the configured limit, but exceeding the "readahead > history". > > So I consider VM_HUGEPAGE the sign here to "ignore readahead history" and > not to "violate the config". > > But that's just my opinion. We're using the readahead code to accomplish what filemap wants. That's an implementation detail and we shouldn't be constrained by the limits which are in effect for normal readahead. Normal readahead will never create a folio larger than the readahead window. It'll get to 256kB (eventually) and then it'll stop. Indeed, that was the problem this patch is addressing -- we started at 2MB then readahead turned it down to 256kB. Normal readahead will start at 16kB sized folios. This patch won't affect normal readahead at all.