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 606E4C83F17 for ; Thu, 10 Jul 2025 21:43:59 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 044676B00A6; Thu, 10 Jul 2025 17:43:59 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id F375C6B00A7; Thu, 10 Jul 2025 17:43:58 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id E73E86B00A8; Thu, 10 Jul 2025 17:43:58 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D58506B00A6 for ; Thu, 10 Jul 2025 17:43:58 -0400 (EDT) Received: from smtpin07.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id 908F6129E43 for ; Thu, 10 Jul 2025 21:43:58 +0000 (UTC) X-FDA: 83649682956.07.02774A0 Received: from casper.infradead.org (casper.infradead.org [90.155.50.34]) by imf04.hostedemail.com (Postfix) with ESMTP id B10B540018 for ; Thu, 10 Jul 2025 21:43:56 +0000 (UTC) Authentication-Results: imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=tTfexU95 ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752183837; a=rsa-sha256; cv=none; b=5wa5y+eq5jFGvD9B4+ZdmFkacOq3t2wn3GoL60NhVup2m+zrv7XPZCtL1+WXIYcm91T6GU CBoTQb2B21D4W4Al6AEiJ8Ucx/0xruMe83W1FJDR87XXPDir+mX3jtmcnOV9sXJ1kn4ys9 UST/m7I12Uoswx61BctP53DxyAgvigU= ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752183837; 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=Yot/lVhOPL+QunGdP+vqzQLV/Yuarw2iaa8zW809OMk=; b=txLKU4A6StD9fl7ORnnTMwufxbu4x2S5ePdZxFRqU6mfh3I3FgMotIkX/V3Z6aD/nN66Gn IhGpe8LuvOiTT5mVJaeBzj6WyKp/8hdXOfzWw7CAKfEtKcj4B9yV1bvDk3ivv31RZ7c8Qp fM2j0TPqR6sth71yB4g3fVc89ow7DJI= ARC-Authentication-Results: i=1; imf04.hostedemail.com; dkim=pass header.d=infradead.org header.s=casper.20170209 header.b=tTfexU95; spf=none (imf04.hostedemail.com: domain of willy@infradead.org has no SPF policy when checking 90.155.50.34) smtp.mailfrom=willy@infradead.org; dmarc=none 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=Yot/lVhOPL+QunGdP+vqzQLV/Yuarw2iaa8zW809OMk=; b=tTfexU95wuWnLKZw6H9Q2MqdAv kE0u8YouiKTJVKTPu078bf93t6z8kaKmy3wd9Y8oM0qzGGPY5W2TYx8IGgkjNUw180P+hIpj9Zxa8 BIMK5GrSuFxA/bcQfGbGx4/A6pp0Wf1POIQ51Pzn+/a++Nu9mdjSZAD1W2pJktVaB/wXS3BlWrzFB w9OfAkD36Iv8vg5lwUJcmWFJGDGRdcdYB3kM5QTFUlf41yu2OVy/SN7ovh+ceCmr4Pekg/K4hzGV9 hdEv5AOUnFStziTQCxjGdRFOvwouHK0xuY2EiOaHlfY2BO62znUYkEusLaqwnUwrAKNwAC5aFGoOB gr8qn88A==; Received: from willy by casper.infradead.org with local (Exim 4.98.2 #2 (Red Hat Linux)) id 1uZz3Y-0000000ARrZ-3VJf; Thu, 10 Jul 2025 21:43:52 +0000 Date: Thu, 10 Jul 2025 22:43:52 +0100 From: Matthew Wilcox To: Roman Gushchin Cc: Andrew Morton , Jan Kara , 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: References: <20250710195232.124790-1-roman.gushchin@linux.dev> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20250710195232.124790-1-roman.gushchin@linux.dev> X-Rspam-User: X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: B10B540018 X-Stat-Signature: mrqmt356akaiokybn41hmmw7dr77byar X-HE-Tag: 1752183836-161186 X-HE-Meta: U2FsdGVkX1/vR3o2NCoC9JN//SdQ9QYP6oLw7y15wIeLN6jVYCNCAgKB+jBXsX/Bfr8zMT5wvTKVcIjl2xUda9j4QpDUMxB3m2exacRkN/NXRSJNGe2Epx4MQa0HTgLzBu+Hb8kZIjODMj0DiprOk11l5/6PlC+RKqBz4kzwVXa0DKDGx8FQqQs3QCcKDx/WGltAkJuNcppDH7AaJq2pcEom8GQocjCwl69TdhW6hs30qY5FoGF83GBMiUCS5tlUNJ1bdj9hSdGFJawWVyM+TyQVzYLcQy0fT5CUbTdRnjJv+GNQKtRW+9ym8oYy7at7Plk4cK/aVeJTbqD6TgBlhKuA5NwXyUlacJ5Qh3NWk3qAl6Mh5PITc9Z13wyyzdZDvlwDpWXQ2gZfaTMA7AifS3oG1A8P56Rnm9cFPxid8yUt6Za+s7VqR9TlvRNH8rbmyIrMx4arfVFePWKsL2qaJUqjxJUAQNAYdDkGwjVMBYI87gCYS07LLPCfDs2CKQ/abGIxFrkzNcrJrx/gb3H55lGlOTQqO6Kvs+yaqLKk+wXeRtFlhJCC1MkwHCKrqNMqOtsO8bmWALjCpUg1i4WX5azoxFT5i7SW4X+OAQTLfhWoREZ9KgnDLv9c3kgOr23g2koFc+ninoUHw+LwBE9TRjGxoHtMlyLJDb1sE0kw/RYY64wHctPu52kzYpKKc6El6BCqf4s50McJ2f7l6iOMvh5ZrM06XrxOnWgH0JxP5JI2Z7GnTQc/h7n4FownKLy1BFnyTt1TVwRRL3vNGHT6Ph9XPJhR/yLdhCsd1TYpQblhQUatGAgNzgjWuqbSk0QmdAQ+KjQIRmxvpRsqOPZqnHYEixna9asKPzMkZ2LlwIo9+3AcHHfett/GFNJNJEqdjWks26j7VI0qrvyidnNId6V2jI73hcfdOMRLuDJ2cGhJ2z9CcWDgczixd3I62WH2FV+pfWPlVqHr15wmi++ A8gL42iD p8MoXj1EXri9wePvkKSEfUQVk8Myhkr1vOXbM6LI/o2JMbElmewIv/6aOwvEAOg1alT8KI4b49uXONkLyqlN205lKyXR0aGFMIbSCQqMb8lUcQVpiB8jXlcoAhFOyuzpu6q2gCMJlWU7J5Koqr4+KNAwG7izhHeXh9cH1oGSfz/JkX8A= 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, Jul 10, 2025 at 12:52:32PM -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. Is the correct response to turn off faultaround, or would we be better off scaling it down (eg as low as 64k)? I like the signal you're using; I think that makes a lot of sense.