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 EA5F2C282C5 for ; Mon, 3 Mar 2025 12:07:05 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 850AC6B0089; Mon, 3 Mar 2025 07:07:05 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 800DB6B008A; Mon, 3 Mar 2025 07:07:05 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 6C8FC6B0093; Mon, 3 Mar 2025 07:07:05 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0016.hostedemail.com [216.40.44.16]) by kanga.kvack.org (Postfix) with ESMTP id 4F3746B0089 for ; Mon, 3 Mar 2025 07:07:05 -0500 (EST) Received: from smtpin05.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay03.hostedemail.com (Postfix) with ESMTP id EC450A3A2C for ; Mon, 3 Mar 2025 12:07:04 +0000 (UTC) X-FDA: 83180113968.05.1339DDA Received: from mail-wm1-f47.google.com (mail-wm1-f47.google.com [209.85.128.47]) by imf21.hostedemail.com (Postfix) with ESMTP id 05B311C001D for ; Mon, 3 Mar 2025 12:07:02 +0000 (UTC) Authentication-Results: imf21.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=dqpucReI; spf=pass (imf21.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1741003623; 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=u4n87D+4TYCPxOP1NMsttu/7Z4wxAKcrq67P7w2tcEU=; b=ZdLp7u4PdH5h2blD4ysh+MtICZxT2eN8/Nd/9UjMNK8x7sADtBuJBuC389K5qVbgD+32cc aoFhK1x9KHx91ztdac/mKN+hwrCEqIY3DXiArVvtBiHSg8nnv1E13GKKlT5SrsyZ/1FFtm 0ZvIFZW+Trj3BbD/B7W1+yGW5dAth6E= ARC-Authentication-Results: i=1; imf21.hostedemail.com; dkim=pass header.d=suse.com header.s=google header.b=dqpucReI; spf=pass (imf21.hostedemail.com: domain of mhocko@suse.com designates 209.85.128.47 as permitted sender) smtp.mailfrom=mhocko@suse.com; dmarc=pass (policy=quarantine) header.from=suse.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1741003623; a=rsa-sha256; cv=none; b=NTmlk8mJGmHxdyD9ecOVBewwoYguQHpBQvsICZUZAPhWXhygelOtSuIpymPciOaV0sU645 2UrgPXIjuPHGNJXDePdeA5ayXDT1/lGQOD0DQZs5WgrXUM6i3hHyP5nOISwRAnFJ3USCck jrLd50xLYP3uNsRDcIZoo6kCvUXGw6c= Received: by mail-wm1-f47.google.com with SMTP id 5b1f17b1804b1-4399a1eada3so39831625e9.2 for ; Mon, 03 Mar 2025 04:07:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=google; t=1741003621; x=1741608421; darn=kvack.org; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=u4n87D+4TYCPxOP1NMsttu/7Z4wxAKcrq67P7w2tcEU=; b=dqpucReIRNscisz3zzY6NzoOWcnPJW0boXwoRDMS1QYHWDEQ8gMulBiti/fuX1HRY2 Pz3qoXyH/z84quIbj8TFLuN+bBKc6ve0ET3p29giayIJVKDDdnGbhHVghDpdWyZjrKFj dGXxE5O0u1fpQGa81aO8jXISkiyWLqZEQ8aRP2u4GuS4ZY0S/1EgwSmHHGvhoCqjz6qB MH/VrPdhMzECXWr4HeyKh9WyDVpMFSe9EFkmS9k0btfV2tr6K4v2t3GEnOhP8WWIyd2S 7Je2v6SSaukPx8W0ssI5TJRZLkaEg7SMAf3cczwUienoSo7U6mMwJoci0rYPRx7wS1C0 FRfA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1741003621; x=1741608421; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=u4n87D+4TYCPxOP1NMsttu/7Z4wxAKcrq67P7w2tcEU=; b=UVeBcESBK3K5Tf2srSBQ/KncmQj3PC+bS7a1xRIqA5ms71lNbeW2tD3lVaY0W6UjO1 SjfP+U9EQy1A0xwF0g+1IBTKE9oCbk7oZIXSHlNmQeyvHLnxx7hoTL0BCKvbPv5J6zBT iHe0K+pE6ksjUITyTLttU9Ql7KpoqxnvFrcUJeZEM8zaxAVqrpLvBJmp8UdK/KBA4G6f Hg7ZFf5DC9tmUGxs1gTOuGSyKYhBeUOWssPxx0QEALwc42SWxlY31aarp3eS/ZmFSKpU PGMRRpFXlBxT8MTuHKCaTP90lBV0K9nzQ0GNQjjWdBEZAr7PlcVN6xJsm2mtD5A73htC vX4w== X-Forwarded-Encrypted: i=1; AJvYcCVH666C5o2AtLHKq0gUpQD5gYIllZNa86rdrQ/fSM2A6fVQqERrFyFZgRu+xhhJDpBiWYcUjIXDkg==@kvack.org X-Gm-Message-State: AOJu0YxxzOA3QiVm7feGQ8XLElXsv4c1lwMH/i3g0hWRDUYCPEFcNDao rDZjRh00noAWg81VHNDBkUsIwVPwZes89RqpXntkmVGqIcIbFd1bS6wlphxGefNUsaPUl243K1N 1 X-Gm-Gg: ASbGncvGu9GQFSOd0xYiwXWlzsDYR5O9+0cMO0ZuLToRwu9PnLowWwlRewNUtgx712R ymxZLgYNcKCIEqWiYsyjEO7U9dlDVcyStLpncq1kbAsQ3/+1wZ5YP2qEF1Jsgc3YHNKGsDLAP2H 7rotjxqO18zgt1m/TYn6vqYciEziwSefMpnMcc7qtq8yhY4rnLLEQIyAxy53ouI9HUOXXEGYI1r 4M5hLWyryp7Kzyl/iwbJPhgC8lqRUD/1PSsvTDgJ8faUvN7mYd1hyuzLDOYjH4KTQ4F4V9LwRX/ +GZUFr348pU6ngfnHXgl780m15EGOO9V7t3w7vyFNrcH84kwd+HmHdhlEg== X-Google-Smtp-Source: AGHT+IHqHfP8DjkalDmAqVAgdGb6muzuQBb7NPew5jiVs8Tdm6zb/yC1t6gsMZUxW4RNTuObE/ckQA== X-Received: by 2002:a05:600c:3c84:b0:439:8ada:e3b0 with SMTP id 5b1f17b1804b1-43ba697f093mr97840395e9.19.1741003621315; Mon, 03 Mar 2025 04:07:01 -0800 (PST) Received: from localhost (109-81-85-168.rct.o2.cz. [109.81.85.168]) by smtp.gmail.com with UTF8SMTPSA id 5b1f17b1804b1-43b694524c6sm163268085e9.0.2025.03.03.04.07.00 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Mar 2025 04:07:01 -0800 (PST) Date: Mon, 3 Mar 2025 13:07:00 +0100 From: Michal Hocko To: ying chen Cc: akpm@linux-foundation.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] mm/vmscan: when the swappiness is set to 0, memory swapping should be prohibited during the global reclaim process Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 05B311C001D X-Stat-Signature: ujspc6wbxnfjccidf3u83ois4ooaj9a4 X-HE-Tag: 1741003622-598381 X-HE-Meta: U2FsdGVkX18GAQanWe6V9g8oZRr5RLWyQRe93RW8x4zIofOZh4eDOzk7pCmrW5TAOQdBg4a1vLNWDZGnF3POVeCMBJMWjjkC0WuAcAeGYivjBjPz13+9TGbmcez4E3/4Ibsr8p+E9fiNtm4Q+kT3l5szdnTUSxVI8ND7sXWUyN7SFDjOsz9HLCgLecmIVJqHu16Yy9QkgR5MLQcF6PyQPR8qo2xNf+6fGgceZpDRMQesMraODp77ag/mQvMqYDqpRCd5Rn45I6pNmCGtL4btUEyazeuqYYl2+gmi9brgifh9mlC9TzKO6a2gvHIPgvXvQdy4HyYS1VHmzE+eTTba6m0axn+NOshHU2aoL7+fEYsKX756V0/+8HK4eqTqYcSyBCWCoiBRcwdxWjEd401Gc4yboNQyrohfX15C6cqBGCJtCRLC1l38tRk16MmV2Ab3BiG8rPRVmmBpZfQroCZWIjmB+7FabAZMB/AI+F5s9UQtcYuTREJ+eRd6tvaxSRUIL3f+s1BlZnT9gmM3A/NnpXMTfPfvWxKzh3SpY1AZ3fA5BacwKSfR5h/k+TVZz2Y8akp03q6s7/+WMl1j40/rnhdE0PWzkTNm2bPznnDPeXxBtSFu3UHI+F5FXXUaSq4m+5nU0M8CNuyElKfQh98yAqMXpKZDdhkpMue/SLUUtnG5GfuWWDfg76GaGIW/YrTiyc22+XD9yQLFGWFG8l/le8w/VdvHeDeNW9UWAGwBaymuYLSQeKyMqtR+k6x0ORRiY2g8xMC27vAggDvQRUubNkBF3iLzcHWmAqSX5ZA3h8MDbLqIlvZDuMKTANSBPNOWL1vY2ijLVIGoq1buJCSdlUy3mj4DUn7cFP3nUZjA2vuHNz4/K+p80NBuIkmEigwMgFYnWUWpETLYM/wPGxjUkfFiFNPkdnHJK3LWVxlECAbHH738koZcI4/uh+6OD0FSKimSwAPia1l77haqs5u 06uCUCdo k8t9p4EDewCo81NIGecduEx9vs7UfkNvmFb6IVQKgeJzbt0d7pkFM8vc21OQl/QVdUTqMEx90kk/hce1SDnwEbTMb3gz4ZPOdkTp2otACVint9NVSYIwyU5Do/K+IBMivVBv4ESVMK+U4QyMhR9Lay8kDmmdeH3B2mH2uKJ9ZYpU0QiIJY5PV2XYHdM+AQ9h0l4o7GW7+NLXqdKy6PnktpPgE1nTRwRcjSIqeSTM3flSR2BkVQ2hw9ovn3Jxa/Uiy/4XCOpilNa8ddiIa111d+jle0nCPClr1NMGN/5OW2qfHs7NLuB8FloqI+uBoYInin5zyOpqeM4Uu4+2FpsI6PqDCtlj7WxDSB78j9VLXJn/8Q/E= X-Bogosity: Ham, tests=bogofilter, spamicity=0.000081, 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 27-02-25 22:34:51, ying chen wrote: > When we use zram as swap disks, global reclaim may cause the memory in some > cgroups with memory.swappiness set to 0 to be swapped into zram. This memory > won't be swapped back immediately after the free memory increases. Instead, > it will continue to occupy the zram space, which may result in no available > zram space for the cgroups with swapping enabled. Therefore, I think that > when the vm.swappiness is set to 0, global reclaim should also refrain > from memory swapping, just like these cgroups. You are changing well established and understood semantic while working around a problem that is not really clear to me. If the zram space is limited then you should be using swap limits to control who can swap out, no? > Signed-off-by: yc1082463 > --- > mm/vmscan.c | 9 +-------- > 1 file changed, 1 insertion(+), 8 deletions(-) > > diff --git a/mm/vmscan.c b/mm/vmscan.c > index c767d71c43d7..bdbb0fc03412 100644 > --- a/mm/vmscan.c > +++ b/mm/vmscan.c > @@ -2426,14 +2426,7 @@ static void get_scan_count(struct lruvec > *lruvec, struct scan_control *sc, > goto out; > } > > - /* > - * Global reclaim will swap to prevent OOM even with no > - * swappiness, but memcg users want to use this knob to > - * disable swapping for individual groups completely when > - * using the memory controller's swap limit feature would be > - * too expensive. > - */ > - if (cgroup_reclaim(sc) && !swappiness) { > + if (!swappiness) { > scan_balance = SCAN_FILE; > goto out; > } > -- > 2.34.1 -- Michal Hocko SUSE Labs