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 0B500C83F1A for ; Fri, 11 Jul 2025 16:29:35 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id A35206B0098; Fri, 11 Jul 2025 12:29:34 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id A0C1D6B009C; Fri, 11 Jul 2025 12:29:34 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 922936B009F; Fri, 11 Jul 2025 12:29:34 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id 8362C6B0098 for ; Fri, 11 Jul 2025 12:29:34 -0400 (EDT) Received: from smtpin27.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay01.hostedemail.com (Postfix) with ESMTP id 377C51DBEE7 for ; Fri, 11 Jul 2025 16:29:34 +0000 (UTC) X-FDA: 83652519468.27.7C82953 Received: from out-174.mta1.migadu.com (out-174.mta1.migadu.com [95.215.58.174]) by imf08.hostedemail.com (Postfix) with ESMTP id 6A669160008 for ; Fri, 11 Jul 2025 16:29:32 +0000 (UTC) Authentication-Results: imf08.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=b2kH2iyn; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf08.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.174 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1752251372; 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=WhuGDLFC4gRIGmhrJvIxGirWHjMh71q+8beAXtBUQOo=; b=0xC+vZokAPuNAVCxawfysSRQnovLKDsT/Eg/KgCDYM1WowSswrjwdjNQGxmVrpFi2O9Otd NtTnRyqU6AkhM41RN5We9EKKJg7ZPWqWPq2SvRDb++LyYEFcHDDuA7bpaS+eCwcnt60fI7 YpucezszwQkpukXXjAf+KxcGH7Httdk= ARC-Authentication-Results: i=1; imf08.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=b2kH2iyn; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf08.hostedemail.com: domain of roman.gushchin@linux.dev designates 95.215.58.174 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1752251372; a=rsa-sha256; cv=none; b=q1x1q7UCEEhOSqNwgDAOSeEwyw5/QySNq+8GLyMtJ4xurO9lLHxauuxa7D1+zS5w0RmGgQ OlJrYxXGOVT+CjHXXypREJMR7Tut1nZL0fDb25M4zoq6RNGsF0P5j5uI59QDwnaOrZghSY kiVjpMIwsglLRFX2Hi4+yIePK2PGZZQ= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1752251370; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=WhuGDLFC4gRIGmhrJvIxGirWHjMh71q+8beAXtBUQOo=; b=b2kH2iynvNunCAs/PZJqW0pEp3JTTlV0Aageh0UBokaogIboKSCl8x0RRjWuij7ZJsTfT+ z3K+V7iGnMwCR6rysOxgBDilxxHoOjy4QEatVzaplfoja57Yxsjl3D5u3tI7xrY+DOAGWd LqXZP8waRIrPYNznRv+/WYHheRybywM= From: Roman Gushchin To: Matthew Wilcox 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 In-Reply-To: (Matthew Wilcox's message of "Thu, 10 Jul 2025 22:43:52 +0100") References: <20250710195232.124790-1-roman.gushchin@linux.dev> Date: Fri, 11 Jul 2025 09:29:25 -0700 Message-ID: <87ikjywv16.fsf@linux.dev> MIME-Version: 1.0 Content-Type: text/plain X-Migadu-Flow: FLOW_OUT X-Rspamd-Server: rspam04 X-Rspamd-Queue-Id: 6A669160008 X-Stat-Signature: amxi64o93ca718r15yw31z9ypgb5her8 X-Rspam-User: X-HE-Tag: 1752251372-686647 X-HE-Meta: U2FsdGVkX18tFjHihT5yX9MzYfFcdIJHlPa/36jD6zWjZ1Ju7BIgy0/0rxUttYcA65d9cokzHXx+M/6AuGWTlyqUg6zQdU3LnXZaiNgbnkGAvfOeEAEbLrOhyMKGGA8pKfltvEMoE9tikAkK3SYwZq1KY8o/vDf2xw+kyAicjHRXyC7ARZZPlocRMdE+SOnQeJf9zFHhoRzcV2ITtovE13bigVD1qM1QuhRCXvADm6uRtKl9cb77TqWUGk0zGAXFH2ZVDyJ1rZlfZkqn5vzjl7WD9GGqTBz0STed0z7zROVtCFzQLyQCBAeRZ9I+AeFYI0bcDmKGM9k5KaKshMs51Rl+CMB/hBBc+cUl/t2os1StP4oj2Acvz2s4iTtpVHg9EP6dISAjZn95BGeUVOpPckpYW/Z3vzMIzWP282ozXIzPyyiCY53Omqsy6kqW0yV4NiWf7GXts4vtJizNpbtrdwpvt44CZBFYcC3WD/6Yof0DGBl2HGkbKwoXUdROxhWjFwHAV0Jaz0JZpIONtemhFn70alrDEXsKs46OIZ5Liglg2kLJklLocPtx/g5uhxu+hLgmCG+UTNLI0/eOR8ee8eZMzvqDoHPEZ9XCK3Lz4o57wgm7fe0IEXDe3zd6cTwr1ncF+AFyHCZHyKwsjJYaXgjhBiZAw+xW7VscRKhsB+kmB0THIzVyL+VcEeKPgY4pFQKfe0H/9ZR9sDTmPOpv+C3FswZG1f95C2gnC++IlUyXSWPOQ4DhRVeIpN5xdX/uAbXb9v9maou/TyDV/O7M50kSmB+lrtmKkNB42hsc9DnUK/JBEcA1yr52umn42qqlq2EaQH9wYJQLydy3LLxjOZ8Fk/75wg6V5df/zheL4O4l5h60esXjmxWickIRGoGPYSKdA+i3fRINQoP9+cF5NHMBQCtAYEkuVGjB3IOiWExQF62r9udTDLVk+qM6URg8f35XJHz3gHpJYZm/0Dz gfrQSBiH 3b7Nss83RONv8q8Z8jVir04KZwuU7PkXUDkmYePhHfpfWMJ7hXH4txCHbzmSIwXQmj0mqBYC25g9t8ZvVw0Zca4Bu0HrPy69bxZLiXcPiN1GAkL73md58JQcoPdSzPvr4U6mBeQgaUacyf0XONall5NWyfYJxZHWp6t7Gz8flOqil//yzQbAn8z5rqkw+9IXrLXK+Wb3Lp9u4kTVWwKRBwszVQuwFqi+R7VfE 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: Matthew Wilcox writes: > 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 think at this point it better to turn it off entirely. For scaling I wonder if we want to scale it depending on PSI numbers? > > I like the signal you're using; I think that makes a lot of sense. Thanks!