Message ID | 20241108141710.9721-1-laoar.shao@gmail.com (mailing list archive) |
---|---|
State | New |
Headers | show
Return-Path: <owner-linux-mm@kvack.org> 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 47539D5C0CF for <linux-mm@archiver.kernel.org>; Fri, 8 Nov 2024 14:18:33 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id C68E56B008C; Fri, 8 Nov 2024 09:18:32 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id C18D56B0092; Fri, 8 Nov 2024 09:18:32 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id AB9696B0099; Fri, 8 Nov 2024 09:18:32 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0015.hostedemail.com [216.40.44.15]) by kanga.kvack.org (Postfix) with ESMTP id 8D4AA6B008C for <linux-mm@kvack.org>; Fri, 8 Nov 2024 09:18:32 -0500 (EST) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 4C0B6C0D09 for <linux-mm@kvack.org>; Fri, 8 Nov 2024 14:18:32 +0000 (UTC) X-FDA: 82763132508.16.14B5BA8 Received: from mail-pg1-f173.google.com (mail-pg1-f173.google.com [209.85.215.173]) by imf28.hostedemail.com (Postfix) with ESMTP id 07053C0016 for <linux-mm@kvack.org>; Fri, 8 Nov 2024 14:17:52 +0000 (UTC) Authentication-Results: imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=nL4GPr6n; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.215.173 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1731075339; 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:content-transfer-encoding:in-reply-to: references:dkim-signature; bh=9/BQL8RJCjStFEA1vUZRU0MMoqsNGEVVN9P8ZLRL5OQ=; b=uz3c0U38sQE+BH62+7NZy0vCl+jXT7Fr5ZCdWz7cNYMzZ6ziuaTbyAWAqQqamManpinXVb IHcZkq3U3sRLVXmFgJ21wyystOGz450ymZmfFwjPFqFOpKXs8/4BXGxuaxIUkYYbU6BfE/ 2Ij1lwr7mow18zim0O4WJzgLaCcEucc= ARC-Authentication-Results: i=1; imf28.hostedemail.com; dkim=pass header.d=gmail.com header.s=20230601 header.b=nL4GPr6n; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (imf28.hostedemail.com: domain of laoar.shao@gmail.com designates 209.85.215.173 as permitted sender) smtp.mailfrom=laoar.shao@gmail.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1731075339; a=rsa-sha256; cv=none; b=hM1nYp/u0aCRM5WcD3Kdsok0cMmH2S/JZjyoq0w0BmC6CqrRKq9ODkuzN1BH0jDVSkoAqP ftkvqrXhxOFof5MXjVcgoUtY38VDOUxtPKONtWGLBXxVLEDcWQhsa9BX7+c5A5+pyRDenw IwiA7+eA9J4eqpnH2MEoA0X+pubabMg= Received: by mail-pg1-f173.google.com with SMTP id 41be03b00d2f7-7f4369a8fc7so366599a12.2 for <linux-mm@kvack.org>; Fri, 08 Nov 2024 06:18:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1731075509; x=1731680309; darn=kvack.org; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:from:to:cc:subject:date:message-id:reply-to; bh=9/BQL8RJCjStFEA1vUZRU0MMoqsNGEVVN9P8ZLRL5OQ=; b=nL4GPr6nOjOpGVJu57oJbsgAahj6YCI9jc0UmiTu7jrqBSMJ6gK36slVGMdCpoz7pr DRKwGP6FWEM6kqoOU8xELwXAGXoETrcLEEqAymiibn7NsxeEnTG7oVP5Ghsssv7r4Qb0 zD1+hWRZQnN94rBJ0EfHzASqufFvHqTl7gBzT32f3M4bbHVXWyncQqHX5844cXu4AE6D 2ndckPYLb8YXlC8zy+wYtSqSDBvZBKIGOCC+yRT+KNzvNZXrBaEG5Atfu6T6VLyX/4kH GOnNYhg2VLx3/Op+GRdILqMHSXVdyLe51foS/TNb0Uls0/psE2EH9p2xX6SN4jYq3OUg /NPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1731075509; x=1731680309; h=content-transfer-encoding:mime-version:message-id:date:subject:cc :to:from:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9/BQL8RJCjStFEA1vUZRU0MMoqsNGEVVN9P8ZLRL5OQ=; b=DNowh58YTLKGy0K5p/vfZlwMkjyBYDn4aLd1pPdkHT9LItzYHkRMGNBd6wARd0wE0k 1om8Q2o4TVXUhpBnoRN1tVyIK5r23NaPBasM5ddoC9WVrn4XXEvHqL3o/sUKH/JLkTai sONIfNw23aba+Ng998dU5vkO+N74Ef2tkw7HtZbrgylDWheF9r2ibK1HJQEkkKR+okB0 mC0dAApki8/dmmQMIbF6ug8Aufsrhi68i2mK2g0qQI1TlTN2t9kxPfdetxlA7tVTD2hu OypBbrMbx/cm+Ir3TzFurYoHK3T78Vfw7te22xvH3FnzKW1d0Y3BeHnefLTj5Zum9fk3 Dp1w== X-Gm-Message-State: AOJu0YxNzEdU94c6xv23Kkvxlz2NZ5i4DCyVd4FBBF8YYUMqBfPLMxjc xRd1n5EMdktqe4Q9NGvF2iA0bzquk5Gv/X0aYIHtDLQUi9cbLHeG X-Google-Smtp-Source: AGHT+IH3c+D72JKSguP5iqxfgtjBvAQWEHR9kwn6DYiM3w5E4T3SEt40wE+/cjQnrEqyPgiCAu/b6w== X-Received: by 2002:a05:6a21:788e:b0:1db:eb76:578d with SMTP id adf61e73a8af0-1dc22b1b587mr4246234637.36.1731075509147; Fri, 08 Nov 2024 06:18:29 -0800 (PST) Received: from localhost.localdomain ([183.193.178.50]) by smtp.gmail.com with ESMTPSA id d2e1a72fcca58-72407a18f51sm3706516b3a.155.2024.11.08.06.18.24 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Fri, 08 Nov 2024 06:18:28 -0800 (PST) From: Yafang Shao <laoar.shao@gmail.com> To: willy@infradead.org, akpm@linux-foundation.org Cc: linux-mm@kvack.org, Yafang Shao <laoar.shao@gmail.com>, stable@vger.kernel.org Subject: [PATCH v2] mm/readahead: Fix large folio support in async readahead Date: Fri, 8 Nov 2024 22:17:10 +0800 Message-Id: <20241108141710.9721-1-laoar.shao@gmail.com> X-Mailer: git-send-email 2.30.1 (Apple Git-130) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 07053C0016 X-Stat-Signature: m763jpnsjiryo73xiawta5qptajhtbeq X-Rspam-User: X-HE-Tag: 1731075472-662180 X-HE-Meta: U2FsdGVkX1++Gft2Lbim4hM4Vkp3q5cqX0jKv5frixRgl+LCKdfy+JfJ7bBtl4n6l7/EODD4gyKUjiLGRJXkZZDasQh96dEWbKZCMCe3ECOl8uOddzZqXEK7hmfMqgnrMKlooyYYcDQ3NdjAYQCv6EzEOG3FVTPupMqGR/53I/RNv064bTaifg5ccx+Z1XGb1X8rEMEVL8qLg3RtX7OvN2G55dQMpm7773F1wG5vS+Ygw0GgqJIcD49fuZ6v4yC0/fXihmErFc7z1qaJGDUq69undXLQo5HFEv3DKfmeuvZpHM0cmoOguopUDS6A12dMt/nniQHd7KzxDDXnO4biLWzuwTkeULXtpW119WGlRaBFj/bPxIV0uPxItbss9zLoMNgZbu1cFYkPoayO6XnJkOEWcchNlgbO0THRHnWkCZ9bSEDTBW7XfosaiYbRUQpuw2mwblhhmpoggBFmaaWm29ctPx/XI1mxWQ9jXyI37b821YE79CIA8xGQ5jcQ9xkCrHDU/G0P0qGJwHCWa8T7IGMURzLMvki/iJJJyrG9T0YQLliaYe8xMF1S9whc6vmt2Uz6sLu7P7hnjmW6L03PmNuFBjSqGURG29eFd6wqOZ4zqH1lbhET2o+GHICLPqZ+W3+DMadePt+fK0zvDCF3MzGq/UHx7zjCh86eYU/OmsPQbqF4iES60+5t/yPFJR4k+xWkR+T9LGOZezJO/pVhKz/13W7pco/gt9MDO89NAC6wujpmciHCXGUFlMoxcgI8s6D6Ggi30PNanI+j62q1dY6j8INmPpJJxFfom/WvoYZQ0n+1P5uYzdZFtVPIZNg1r6Ss9NhybXp3Hnj06sLe6EXjb43HJJ6EnoW4ej2j7bfEXKqIWOQ19rgy0oNVNlzOtdbR+KOkG/GjmfShx3Hi05CvDHO/DVAzGpLqs7tU5qKvVPi2Aoq/KH0CXrUq/QZ13jNB0YhrY24+op+TUfd Fg94w9o5 AXnH8XKhH7uZwoWgWt4JXQzHfd9PR34OZN0Ar7Mko7FrBlSobsM2EnHcyOYNkKRfIbMg6oRzUq3yKSUUefn7F11ulYO0DN8wkt6E8qofV6cX0brM5VJkYz7LRBhpZeztkYZ6w+agRgp9BnVUhaWjgsGWktDEecHKkz4dx0WK7dRckAmImvRbNicOK+350b52Foe0T+KG2Hsc61LjoMq7a1qX4gL1t0nYC/Qf+R+Q47SMubIWvBOzHq9rad4gSOi+m6M2YfbqOtXNyK6sLkEsQ3SYI0fi3cyJFOCdxpIg1J0nNJjqw9i2bAEIO9aThm19mbFHXi7imriz9E3AcpCkdcPZpwOHownov0+scc2d/g92PivU4MZu2hE09uxWCXHBJfysercnP59OSJDVhmVLL9WQn/G9GEzyM9ZEH+KUdDGGNLhhCQHrdbEKiDCj/TXFyP7sX/2hkD7bmUbPnXa9wck1M7I5SAxecgbLG/nKBGLbuTDsElAJCuKFNC4B1ounpCFlBYgMwnCdBaTiAtn1lZOkzVRarT+OLAQ9DsjaLOzlzqdllA4Ypn/AsBw== 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: <linux-mm.kvack.org> List-Subscribe: <mailto:majordomo@kvack.org> List-Unsubscribe: <mailto:majordomo@kvack.org> |
Series |
[v2] mm/readahead: Fix large folio support in async readahead
|
expand
|
diff --git a/mm/readahead.c b/mm/readahead.c index 3dc6c7a128dd..9b8a48e736c6 100644 --- a/mm/readahead.c +++ b/mm/readahead.c @@ -385,6 +385,8 @@ static unsigned long get_next_ra_size(struct file_ra_state *ra, return 4 * cur; if (cur <= max / 2) return 2 * cur; + if (cur > max) + return cur; return max; }
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. After a thorough analysis, I identified it was caused by the `/sys/block/*/queue/read_ahead_kb` setting. On our test servers, this parameter is set to 128KB. After I tune it to 2MB, the large folio can work as expected. However, I believe the large folio behavior should not be dependent on the value of read_ahead_kb. It would be more robust if the kernel can automatically adopt to it. With /sys/block/*/queue/read_ahead_kb set to 128KB and performing a sequential read on a 1GB file using MADV_HUGEPAGE, the differences in /proc/meminfo are as follows: - before this patch FileHugePages: 18432 kB FilePmdMapped: 4096 kB - after this patch FileHugePages: 1067008 kB FilePmdMapped: 1048576 kB This shows that after applying the patch, the entire 1GB file is mapped to huge pages. The stable list is CCed, as without this patch, large folios don’t function optimally in the readahead path. It's worth noting that if read_ahead_kb is set to a larger value that isn't aligned with huge page sizes (e.g., 4MB + 128KB), it may still fail to map to hugepages. Fixes: 4687fdbb805a ("mm/filemap: Support VM_HUGEPAGE for file mappings") Suggested-by: Matthew Wilcox <willy@infradead.org> Signed-off-by: Yafang Shao <laoar.shao@gmail.com> Cc: stable@vger.kernel.org --- mm/readahead.c | 2 ++ 1 file changed, 2 insertions(+) Changes: v1->v2: - Drop the align (Matthew) - Improve commit log (Andrew) RFC->v1: https://lore.kernel.org/linux-mm/20241106092114.8408-1-laoar.shao@gmail.com/ - Simplify the code as suggested by Matthew RFC: https://lore.kernel.org/linux-mm/20241104143015.34684-1-laoar.shao@gmail.com/