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 E8701D1BDC7 for ; Mon, 4 Nov 2024 17:00:32 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 667C96B0085; Mon, 4 Nov 2024 12:00:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 615226B008A; Mon, 4 Nov 2024 12:00:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 5040A6B008C; Mon, 4 Nov 2024 12:00:32 -0500 (EST) 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 315496B0085 for ; Mon, 4 Nov 2024 12:00:32 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9622680341 for ; Mon, 4 Nov 2024 17:00:31 +0000 (UTC) X-FDA: 82749025506.05.6FD04FD Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf09.hostedemail.com (Postfix) with ESMTP id EA15914002E for ; Mon, 4 Nov 2024 17:00:06 +0000 (UTC) Authentication-Results: imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Gp2Dyd9L; dmarc=none; spf=none (imf09.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=1730739507; a=rsa-sha256; cv=none; b=7iKckN5lE2TGDSndbykkwRzCiqnxywaOuD4Fqn3oeLZWw9EhH2bNsT1pPgGWDscz56iUqy lGtpBaj6Jjm91anq6nMGnYXnjB8WKruQ+NrhVj3tB+R42H9NbTNNTtEWvfBeMu0K8359YP WFUZ+ezXZVuR4NUjJtNCuw+8cbevs6Q= ARC-Authentication-Results: i=1; imf09.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=Gp2Dyd9L; dmarc=none; spf=none (imf09.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=1730739507; 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=jHWf+xo6Hty74VhgTgjGO+bFPEXxFWiVi921r/6Bn/U=; b=f+s8LFr9kPk1D0p13kSxHWbkjy6411vhMCtlAK1XviuLqLvIjX3luHX32o5YzmsCt53dzY 5z3Cu+22fU57CaZf9LCDzqaFGS4tGjnlUvNVZt1NLq9SGdXuVetmoRyLqRdW1Zs5LMxNsN 2R4B2mb9HyaMM0X9E6ym2uTIIRwFoqU= 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=jHWf+xo6Hty74VhgTgjGO+bFPEXxFWiVi921r/6Bn/U=; b=Gp2Dyd9LHW42CFSDP4Gg8u5bXH zSwQYA1cIBaGEeof/aXg4vvxkElpnwBBWDaLoDpSsjLRw98nDwGJXxjqeBYi1JXCGdmelaQAUaR4d BVD8RPgBnhvMcEh3oQZIgB3naNaDz2DdYbLxpQwmenL5vpTbRtSvmouACzmk4pw0pS7grH3DjUmtE ju0PVmEgkB4mqF3DaTzWhyQRSl079jLa/Ovyo0le4VUpfJLmOy8MA/C1L/eD/soAuy/v/DQfzUkS4 yo35bm/WD/JSiK7S19nPrD/1t7GDctwoThW4zvEO8/HT7POdT5a0GyB0H69Wtvu0W4RvVs4ppxK/w PgHUMx4w==; Received: from willy by casper.infradead.org with local (Exim 4.98 #2 (Red Hat Linux)) id 1t80RF-00000001Nl7-0ezr; Mon, 04 Nov 2024 17:00:25 +0000 Date: Mon, 4 Nov 2024 17:00:24 +0000 From: Matthew Wilcox To: Yafang Shao Cc: akpm@linux-foundation.org, linux-mm@kvack.org Subject: Re: [RFC PATCH] mm: Add large folio support for async readahead Message-ID: References: <20241104143015.34684-1-laoar.shao@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20241104143015.34684-1-laoar.shao@gmail.com> X-Rspamd-Queue-Id: EA15914002E X-Stat-Signature: ud4c1cayr8nhrpdjnz3ny6c6ps4bghfy X-Rspam-User: X-Rspamd-Server: rspam05 X-HE-Tag: 1730739606-614141 X-HE-Meta: U2FsdGVkX18LOcEbsKcgsqaBZT5pR3ASivNmNvoxCeD8wnn2gb+RkL4ofixROIpunOVjSZezmkbdRXHj2wNdkqSoFTqMpGfQEiOx/VmpCUDVdte5V3QGYfVFb8LArPBZQHE73QD5C/IvXh1o5auhnHss30lQGTbTZt+/fsFYu8vMb0RasxoOQqyfJ+x3d4wlo53WpzJktYpwwvwv6PgyzxOSbdwp+kxRFvQnYEHQ5CQH85POghgUGr2IdgAF7AXr9CON8twLiNMXRaJhawnbfx3x5wV4CTLDSgYyKYwb+lrXuReuWWU0mGuwYbChzw9ffpG9DSgyaKNoyoqlGa0I4KAboS2koYC+Q4TDzDRqkrTHWAXLTO/x9hriPpD57Vd1hK449/PWhji1zdHxu2jLlwBVFdQ4Cdhbzrm3+gmI2VssFrk0IxJpFZtVMdiCzd/yUUYpsxRfEpWFMQh4rq308cPH14ptB4CMvkRrpB6RfV1eAPfEDWDZqB13hlX+pCdwc++uSuHdo4aUDdQE4XDASkSwP66XpRLivLuWVEhY5wT+hX488/CJJ50qgS91sbcgRTVwW+ck+w0m9GIkxQoz6M9QxVhDidmP7+IqMprd94qMaW+sAJiAzTn1KG6ZMaG0uv7oh1rN2F0XHMOWoagrdkwmdXeD6tKvDWRKi0HorCE5cbLO/MiIrBfU9rUrLpqQSbvp0gs6MLZV1e/6A2n8OLoh6Sj7ySRQANn91z6jWfSykrQQJQatpS6gtHa3084mB9THyT7du8h0THLB0Fwtwi+fRNtizDCIhJyUWHMer75zqwhM4g/KrJBDLQT1WMgPpzRxXyq/JS88+A4+73C5EeUpaF5G6NSbUdw5nibdLauJ6iZKzJKD3+FEXOAzRkw6/+CteGZkj2u3GyMDrIpW9+COc3AIv6V+FhTTeTr8w9p6GLMpawYTIZ6Hlnqacq7vDiIyAeqkWjxUu/i5jyx ldI3YOKq 2zCcJdF4ed8gEyt/evF8rU7mISZ07Xv+AYS4026ETK/pDeebqFZSIMx7s17d1G23z/Z2yxajQ7nBSLFsNB+2oUuS232E+lFW1ixLm3RI95MPADxlhjbJvHUhxykHLpQofGHAt9MIUQlkcLXZfNb1P+wQz5F5ojooOPIpUIz0ZqDpxhJiX/H3xfEYCZdBom8h/wKFHBse+vpZV1wIQYCuD7K2vaTtSIWZ52a3gUt6kPSwk/Hn3X7faD7S13Fc4YN+S4IkX 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 Mon, Nov 04, 2024 at 10:30:15PM +0800, Yafang Shao wrote: > When testing large folio support with XFS on our servers, we observed that > only a few large folios are mapped when reading large files via mmap. This > behavior occurs because large folio support is currently implemented only > for sync readahead, not for async readahead. Consequently, while the > first filemap fault may map to a large folio, subsequent filemap faults are > mapped to regular folios. This can be verified with a simple test case, as > shown below: I awear I tested this and it worked at the time. Here's what's supposed to happen: You touch the first byte of the mapping, and there's no page in the page cache. So we go into the sync readahead path, and force it to read two PMDs. From your email, I assume this is succeeding. The readahead flag gets set on the second PMD so that when we get to 2MB, we go into the 'time to do more readahead' path, ie the 'do_async_mmap_readahead' function you patch below. Now, page_cache_async_ra() does this: unsigned int order = folio_order(folio); ... if (index == expected) { ra->start += ra->size; ra->size = get_next_ra_size(ra, max_pages); ra->async_size = ra->size; goto readit; } readit: ractl->_index = ra->start; page_cache_ra_order(ractl, ra, order); So it should already be doing readahead of PMD size. Can you dig into what's going wrong, now that you understand that this is supposed to work already?