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 92421C48BEB for ; Wed, 21 Feb 2024 22:30:18 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 1C64E6B0072; Wed, 21 Feb 2024 17:30:18 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 14FB46B0080; Wed, 21 Feb 2024 17:30:18 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id F32286B0081; Wed, 21 Feb 2024 17:30:17 -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 DDDCF6B0072 for ; Wed, 21 Feb 2024 17:30:17 -0500 (EST) Received: from smtpin15.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay07.hostedemail.com (Postfix) with ESMTP id ADF17160B9C for ; Wed, 21 Feb 2024 22:30:17 +0000 (UTC) X-FDA: 81817255674.15.CB6505D Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by imf27.hostedemail.com (Postfix) with ESMTP id 075B04001A for ; Wed, 21 Feb 2024 22:30:14 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=IKSCSYPd; dmarc=none; spf=pass (imf27.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1708554615; 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=m2XRvTZK7SAcYpfizhXRcsLlfXX2SRGEJbRRfoRM5Oc=; b=Yfwf+BHpHCXtR5ZHwFFBMGWp01dkHn3j4OrcrQpFn3B5FdKEYPkBIlp8+GzfRjOk3uD5Es NXhzusyfGPf0wH4IuIPF3CpCTlds1Gz6THTaAQfBUp2TGnIiyIenTGWYb/o/PKP1c0fmO7 LrlJ3rteuzlHjv+xkzjUoZO/egZEjq4= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux-foundation.org header.s=korg header.b=IKSCSYPd; dmarc=none; spf=pass (imf27.hostedemail.com: domain of akpm@linux-foundation.org designates 139.178.84.217 as permitted sender) smtp.mailfrom=akpm@linux-foundation.org ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1708554615; a=rsa-sha256; cv=none; b=SVtvGWYmt9qfV0ernKmdqMkQqbrEsUm1SgEpHoGb84AwVFNxRA0+8ejw0XzLZ3ikvPQPjB bswKPYUOBxY3/w0C7X2oBRF9Kj/j84wYqfhyrDI8Oc6LgcCn9DyIW8i6+HPpqaxd6xAxON 4MzSdMKnKMYGOmTitFjo2DGji4I+lPY= Received: from smtp.kernel.org (transwarp.subspace.kernel.org [100.75.92.58]) by dfw.source.kernel.org (Postfix) with ESMTP id 20CB261602; Wed, 21 Feb 2024 22:30:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 91630C433F1; Wed, 21 Feb 2024 22:30:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linux-foundation.org; s=korg; t=1708554613; bh=GU7BcpQegK/Po/OrazsdN3umuvQx2U8gfB37BUk9oaM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=IKSCSYPdaXS3m4XBwaV529Y9WSat1k7rPJMU+j1OFvO+L2/5dr5bBeBIdjalBytpi TkqTHqaYMLShAITeks9Zs4m3aAUQFs2azGSu9G7UWUjPGjTQOQ4qelDkCrDUlTn+Ly SYmU/YF2+MdeLaGeAafH+HLapQtdF+8eAL/jrYDI= Date: Wed, 21 Feb 2024 14:30:13 -0800 From: Andrew Morton To: Yu Zhao Cc: Byungchul Park , linux-kernel@vger.kernel.org, linux-mm@kvack.org, kernel_team@skhynix.com Subject: Re: [PATCH] mm, vmscan: Don't turn on cache_trim_mode at the highest scan priority Message-Id: <20240221143013.d130b310a1306dfed0f6603a@linux-foundation.org> In-Reply-To: References: <20240208061825.36640-1-byungchul@sk.com> <20240216072434.GC32626@system.software.com> X-Mailer: Sylpheed 3.8.0beta1 (GTK+ 2.24.33; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Rspam-User: X-Rspamd-Server: rspam12 X-Rspamd-Queue-Id: 075B04001A X-Stat-Signature: 3mgq6dw59yjjryeb18iwgs6633q8oi1t X-HE-Tag: 1708554614-782701 X-HE-Meta: U2FsdGVkX1917W+iOlLNjgfRzUwMrVpEqOtj7FxNqs4aOHdu4O3DzdjeoXsHkOMSwgKf1Ksx2uEhMthBrMSbrMlXPMjmC6lWHNOL3bg914gIA3w+ulcVzHZ8ToRGxvqxirVJeQMw37ThvhYxg8smJh6DlMhtr7k0Nj9h5PEi/ZwC2unQLe8VsOxDALbXe/elHUxiFe618VNOTTABfuBZgH+I4ZitLA8P/ff0smgg9ruczka8XD9Wx4aUpMGCtNLhU9OhKtpr2XECF+vILXcsU4h7ky/3Q004OLjzjGF7t3z8WVeLjBvmpYGEMNUi5N05XxP8JpQGILB9gYZSk5/zXTT3U7aEAKsoSCKVLzNAVeNd4HEO1QgJARrBoKf9PAjBrJ69a0pszMXIwfQLglKiRyPCyh1Az9HXOMgXz17Y6djX0hkIpgVzM1O8CoRSAblm0Ey5LaZz7Wq663uXRHiIX2V7vpADtU890BHWDkCvQueyzw+hYlhlrSztS/Mtsd9ukojYxqUA7fEdADShwrUhWYnxS8j4nmkzTfndQPaRwQ4FZT6NcH+GSdV2wXahVAYPBcCK/TgAUN39i8m5Ykm+dhBU/UP4owEasZ+owjltfn+TDgFue8muN5/zruBaTVEqMX5TwFrekj8CgufF+FlU9wbTTuTyLM86GYyarb4Krxyo8IWGpGCTTD1ahYbdnGwDG1yS05gOEwv7NAL6mbzI29sFWEOcIm5Z6Ll0VAJ5HkYzTbrr0Ssj5EaoiKiIF8YAJTBymyl3axbDwZLMlpKhamoFFm4DJ1gQyGlD0IIpi7yn67imi0kVutMDP7uvZHQWW3A9lUIZw5fjOOKA9j6AzPaAShM043jLdRqHdhjLEgkRKyFcnnrmO37H4Y/aoqbOxfllTbkQcL2WhvnCLdIT1OOsZJee7RkQFwS9vnlWMbH44BZmUIcVZm/LbIdydCmV0wZKUrv1kguYHKyslbH cVcPRIkZ DJ/1x 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 Sat, 17 Feb 2024 00:11:25 -0500 Yu Zhao wrote: > On Fri, Feb 16, 2024 at 2:24 AM Byungchul Park wrote: > > > > On Fri, Feb 16, 2024 at 12:55:17AM -0500, Yu Zhao wrote: > > > On Thu, Feb 8, 2024 at 1:18 AM Byungchul Park wrote: > > > > > > > > With cache_trim_mode on, reclaim logic doesn't bother reclaiming anon > > > > pages. However, it should be more careful to turn on the mode because > > > > it's going to prevent anon pages from reclaimed even if there are huge > > > > ammount of anon pages that are very cold so should be reclaimed. Even > > > > worse, that can lead kswapd_failures to be MAX_RECLAIM_RETRIES and stop > > > > until direct reclaim eventually works to resume kswapd. > > > > > > Is a theory or something observed in the real world? If it's the > > > former, would this change risk breaking existing use cases? It's the > > > > I faced the latter case. > > > > > latter, where are the performance numbers to show what it looks like > > > before and after this patch? > > Let me ask again: where are the performance numbers to show what it > looks like before and after this patch? > > > Before: > > > > Whenever the system meets the condition to turn on cache_trim_mode but > > few cache pages to trim, kswapd fails without scanning anon pages that > > are plenty and cold for sure and it retries 8 times and looks *stopped > > for ever*. Does "stopped for ever" mean that kswapd simply stops functioning? If so, that's a pretty serious issue. Please fully describe all of this in the changelog. Please also address Yu Zhao's review comments and send us a v2 patch? Thanks.