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 799BBC83F17 for ; Thu, 10 Jul 2025 20:57:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 963396B0093; Thu, 10 Jul 2025 16:57:17 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 93B436B009A; Thu, 10 Jul 2025 16:57:17 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 89F5D6B009B; Thu, 10 Jul 2025 16:57:17 -0400 (EDT) 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 7D9E36B0093 for ; Thu, 10 Jul 2025 16:57:17 -0400 (EDT) Received: from smtpin08.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 0C4D3815E2 for ; Thu, 10 Jul 2025 20:57:17 +0000 (UTC) X-FDA: 83649565314.08.01CDBFB Received: from tor.source.kernel.org (tor.source.kernel.org [172.105.4.254]) by imf06.hostedemail.com (Postfix) with ESMTP id 3E792180009 for ; Thu, 10 Jul 2025 20:57:15 +0000 (UTC) Authentication-Results: imf06.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=2ZBT9MbZ; spf=pass (imf06.hostedemail.com: domain of akpm@linux-foundation.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752181035; 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:in-reply-to:references:references:dkim-signature; bh=/tznqHeb7+WE9SMgxIXCaIulRdP3RDwDVu0glB05hF4=; b=rf6PbAbt0pvSvVJtml5B+FiQ2A/r8crR1+5tIwVLJRNlFbFUuEsoqmcpZlXQ6RR3uq/o9a ETDwwfXJowxS+NJtMnFARuJCanJqn6RU7UP9cECTCCzblcrgbb4e7Jlcv6Eu1AvSieAP02 I9u87XevD9nnf3mXRIyzOgMRcV/m+RM= ARC-Authentication-Results: i=1; imf06.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=2ZBT9MbZ; spf=pass (imf06.hostedemail.com: domain of akpm@linux-foundation.org designates 172.105.4.254 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org; dmarc=none ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752181035; a=rsa-sha256; cv=none; b=wOp3axdlZdx3ub41NqUGoJ9S0L7fJd+vZqvUxBSyeyRdr2zlIP5jt6kLAHLGoF7gtuLvdI mH3+uxbQvLLFHBN07N6lVM4EaKECbkjDNkrsFwDeGst8GKeC2sWoJITRhw+tsDO4RtDeVB OIviTFCK8Ufz8oUnp0nCmA3ACXvQ1jQ= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by tor.source.kernel.org (Postfix) with ESMTP id 4BB3561148; Thu, 10 Jul 2025 20:57:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id C7A1EC4CEE3; Thu, 10 Jul 2025 20:57:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1752181034; bh=PgvdOHSZ/NTpEg8ByNQ7lOO3bzSndi9o3WTFutS94oc=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=2ZBT9MbZuwZu2B2D/nPBpGQgH+Ia64+2HJtj3QLESe4/1O3kvnr3ehU+A5m5OGgsR u09e2kwEGx3O/J1YdlyNGasfdgov/nRTuSa0i6ilsLb4AADwHPbs2c9EV03gULA/zF CScW+C1BStm9M+maVUaLqQI3dGqKOuW4AuBgiM94= Date: Thu, 10 Jul 2025 13:57:13 -0700 From: Andrew Morton To: Roman Gushchin Cc: Jan Kara , Matthew Wilcox , linux-mm@kvack.org, linux-kernel@vger.kernel.org, Liu Shixin Subject: Re: [PATCH] mm: consider disabling readahead if there are signs of thrashing Message-Id: <20250710135713.916a4898fb02f595206ac861@linux-foundation.org> In-Reply-To: <20250710195232.124790-1-roman.gushchin@linux.dev> References: <20250710195232.124790-1-roman.gushchin@linux.dev> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Rspam-User: X-Stat-Signature: 7zi7yjwbb6w3ru3nwxrd1csaxixg1ank X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 3E792180009 X-HE-Tag: 1752181035-887726 X-HE-Meta: U2FsdGVkX19nREcGeA2XB1PRiqQUXL/GGkQovclQLY25xEMRMoUW3ZECVCKKmc8JIwB5rx4RmmRZuo1w6rjDk5LWEBo9RO5Uh4IrUhdZi47cSjBVMJt96t4JE5yKquiXYqhvqdV+Y4Ben+3COb2P1XXs4X/Sbrvrh9A1jvQybbsN/FBIzUyiaOg4z9WDt9sSzVsj2P5Bpi8hdQGtdnKhV9mgj/sLhn/NBu+m9WTuA7cUZkbpVvYfmB2CnzyDkxBviY4Qtzg5rRKFioMSMJ6S7QJJ3hiE+GKKK/AJR2DX48vP2ETU2ixMOAIZAs3B/D5ekwYuMdaNRFWy2zPxo5kECUVvA5WCqUYJgWiJ3eTLoIxCPd6WBFRCOkH8Hq9mZ2XIiiJ9YVTdqOyr41NqErIhnTUNyxOP8kfnOwZcFk3xXP5oIgDRBjiE2QIDTJe6hr91jQ1l9coGipSgpI+se+fcdV/7v9rLO7ajkKH1N9oNX4QdWkuQHCzOsz48tVL7/8V6PTh14+15WtNRJoaI5NqjYd2QAvt7SR/OjyaguQtWGdPig3JISL5BCmKbVSxMUEwlqGPX97N73PIxHc7ruJgZY+/QZqdOCgvG8KUR3GJQPlkRHDgAjoDZfWOuzrfU5xWj0R8y+IrOe+O4IqbMupq+RBGkU3WTvERHmXPy6V6SwQl545nc8CosEsvIZll3ZIyODhus2tTAiTiwJfJV4zwywsWqnzqnHbaeaik1CkJUkWkA6unNSZW5Ed3nrUbGWz1KOPsViptNg9JXfWP3TmKiPKDWw96zffv8XVFPY1gX35f8KNagGwY2Fk+EbwTmgDg7DohfI88YGlKoMeyQnh8l0VDm89tXuRl+/zy95g899oLquN/Lso1Ld7m0Y94RHPF9vjT/Etyc6FxroBayETgx4g2MBV3p96WpUweu1mAcbl7g1xbHQ+iq4pjM8JMENtBYzNj85zL4vhD8+ixFgyi lobXPDTh sjYL+iQ1vN2iiTYbUfnXa+Cxm/c7I0kaQuqWXjwrUt5Er+ydJsl/MWt37N++7kauNv2WX0wrUgMsde/fmI6uy+uTJC2zTh30u5372FpShLykX5JPOPavEXTpCEn5cffy3vQ7ghsJtbyQBqT6XEFn1mSTvBUUBOn373EL84Et1/zKiPPenZrl8BZFgli3FoePOdfGS6+PJRaHTQQQpQrlkUDx3aERrzj9cDdaf46qOzToxr+g8WkpXuO7e6w== 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 Thu, 10 Jul 2025 12:52:32 -0700 Roman Gushchin wrote: > We've noticed in production that under a very heavy memory pressure > the readahead behavior becomes unstable causing spikes in memory > pressure and CPU contention on zone locks. > > The current mmap_miss heuristics considers minor pagefaults as a > good reason to decrease mmap_miss and conditionally start async > readahead. This creates a vicious cycle: asynchronous readahead > loads more pages, which in turn causes more minor pagefaults. > This problem is especially pronounced when multiple threads of > an application fault on consecutive pages of an evicted executable, > aggressively lowering the mmap_miss counter and preventing readahead > from being disabled. > > To improve the logic let's check for !uptodate and workingset > folios in do_async_mmap_readahead(). The presence of such pages > is a strong indicator of thrashing, which is also used by the > delay accounting code, e.g. in folio_wait_bit_common(). So instead > of decreasing mmap_miss and lower chances to disable readahead, > let's do the opposite and bump it by MMAP_LOTSAMISS / 2. Are there any testing results to share? What sort of workloads might be harmed by this change? We do seem to be thrashing around (heh) with these readahead heuristics. Lots of potential for playing whack-a-mole. Should we make the readahead code more observable? We don't seem to have much in the way of statistics, counters, etc. And no tracepoints, which is surprising.