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 B0F28C54E67 for ; Wed, 20 Mar 2024 22:38:49 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 240706B0083; Wed, 20 Mar 2024 18:38:49 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 1F0166B0085; Wed, 20 Mar 2024 18:38:49 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 0DF896B0087; Wed, 20 Mar 2024 18:38:49 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0013.hostedemail.com [216.40.44.13]) by kanga.kvack.org (Postfix) with ESMTP id 003686B0083 for ; Wed, 20 Mar 2024 18:38:48 -0400 (EDT) Received: from smtpin24.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay02.hostedemail.com (Postfix) with ESMTP id CD69C12076C for ; Wed, 20 Mar 2024 22:38:48 +0000 (UTC) X-FDA: 81918883536.24.B8597DB Received: from out-189.mta0.migadu.com (out-189.mta0.migadu.com [91.218.175.189]) by imf27.hostedemail.com (Postfix) with ESMTP id 00AD04000E for ; Wed, 20 Mar 2024 22:38:46 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=URTtPPLS; spf=pass (imf27.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.189 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1710974327; 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=fdASLFv2/fpQ2J/Ny9c7D56INI9+Df/mhIjRVwm3hrg=; b=osIs4PeoOh+jwInWawS9L26oCn/fh/azhcEElcLdGEFatPBX8aUGlVpXdsq62bw5H8qIwZ yR91VrikTrDlqtyuP5+grmvJtQiT/okI5SIUoPmyde/Leo4G1VvE8xupa25gMMYrAlAi8G PqS0qCtWuLn+dJszDpYZobZD234o2Q8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1710974327; a=rsa-sha256; cv=none; b=P62DDL2szetKb2muPSm/cOMHwZ6rkOBm3emE0sidxWCmaBumWXxIDxVYkLER7yQgPhoQkc mKh4TuIEkrKwxdWSkJx1kWzmr4Co+VV3tD4fFfN3ERgBrjCorpnh2FibbzyWag8TNTA7Xb 11o2CWlAoKxsQnIF1XKGFj48XJ7ltic= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=URTtPPLS; spf=pass (imf27.hostedemail.com: domain of roman.gushchin@linux.dev designates 91.218.175.189 as permitted sender) smtp.mailfrom=roman.gushchin@linux.dev; dmarc=pass (policy=none) header.from=linux.dev Date: Wed, 20 Mar 2024 15:38:40 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1710974325; 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=fdASLFv2/fpQ2J/Ny9c7D56INI9+Df/mhIjRVwm3hrg=; b=URTtPPLSThfeQKeOGopVvqEwoBcfCWf55w/sMysnz0BWAaIWc23oX13AwEypZm92Jhv6U8 RdRh2Y3lNzCR09xWufVKFdcBEH3AR2XAw+qwB91xNKpyCftCanX6cXA9QSqE64r5yO9Is4 87gi9/lRigNTzlOM14FGLeK/GBcvZB0= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Roman Gushchin To: Pavel Tikhomirov Cc: Michal Hocko , Johannes Weiner , Shakeel Butt , Muchun Song , Andrew Morton , Vladimir Davydov , cgroups@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, kernel@openvz.org Subject: Re: [PATCH] mm/memcontrol: stop resize loop if limit was changed again Message-ID: References: <20240320100556.463266-1-ptikhomirov@virtuozzo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspamd-Queue-Id: 00AD04000E X-Rspam-User: X-Rspamd-Server: rspam11 X-Stat-Signature: dshcd1m399t8xao9shjqj9u4upna1ry1 X-HE-Tag: 1710974326-590882 X-HE-Meta: U2FsdGVkX18s/NleVeBAChq03Mo5z/19UdyY+8d1DPmoxwZ4OAhVq8DQstND0NRFQYTepfx/WupNx61vB7mtDXflnYiDQmoOSOMIWL3xc8HuBbUrNT5LMRIf6VlXrbks00vSjBeRmHH7Cer7nMvaSF9wfwUtqC59uTSh6ERFbQrM53oh5nV2OoQt9jNbe3T4oBVkHxSie+Or1hbyFQS9aOOfpwpx6GWo14vMNxbkZwG8mRQhESMbk8WDvnEsygCX61mqCn1De5xbuYZP9fhlkwxtiysCj4CosdOH/Qt865baPSuaWhzeBAspTvCG3Ty5fb3XufYPkKB7hwBCKwtCRGNKnAl87iijVkmJsDWs1Th8LXo44gWAiL/YYNrmjpYyu/coGYMw8Fk/xopvFB+N1gyc/xWQtTqK1a0PiOw2paBQsxwx/pVByDHHlwmBL0Wdl4NIff6LeHq+/favIa5/hC99wL5nkw+ZzqMLrAQMeNVsfpvcrRct/KuUxhvfLvZsV50UvYUGX7Q5JPaSyB0CQVh0eh64EqfU0aVc0BIYWpkeFTYushg5mgsZrUhp1qWk38SuZzZS6hsue0KHKO8oYK7kwgPPcc1CY3iOhcb9pC3Kj/SRQPHbF1gZ4oxbNTocT7SahBi7wAFfPPKsPFYBpXqM4gADP6k+Y30n6L1YzsfMwJjEWGpEyAwGdSSgep4FliuQK1bdC3OdH1ihgYuv+xUoW4NzaJApC5k1oE5V5c0GZ6wEdAXh1SmdJqUSS+91LGhEU2r0nApH+2Pcrqcyi30FihK5z0cdGH/JDjE6Z9oy+nREAjn3aH97Gigoce8kd6SGX6cAJxtcLR+hQDEpij1D0tQ4654LJ0F3GkNLEkkqXO91zQfjguoYdl/a4GQC8C1dD5Mvk4tv0QxPIdlzvrdjRXFEHftiQRGtzCyVTEuW29dVeZ0Fp9LhymEVIA7icIhGv2VSUGdmmwEvzVp BsdWQBtg CbOJZ+8teHvAFBS/7ovdPQQWHYSRif+lhLIYoi0dJ5nzsY14PwAzAcXWIrYkj0on2UA7giQOgQaPsCbNnRpE7Hp1lEZjQNB3ChgCuAjsGZ6wmaNL0qqKNAzXP0pe2HzE5FNu1P92CVWHc7UKbUbEsvtx8dYDKu0BI0VTv 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 Wed, Mar 20, 2024 at 06:55:05PM +0800, Pavel Tikhomirov wrote: > > > On 20/03/2024 18:28, Michal Hocko wrote: > > On Wed 20-03-24 18:03:30, Pavel Tikhomirov wrote: > > > In memory_max_write() we first set memcg->memory.max and only then > > > try to enforce it in loop. What if while we are in loop someone else > > > have changed memcg->memory.max but we are still trying to enforce > > > the old value? I believe this can lead to nasty consequence like getting > > > an oom on perfectly fine cgroup within it's limits or excess reclaim. > > > > I would argue that uncoordinated hard limit configuration can cause > > problems on their own. > > Sorry, didn't know that. > > > Beside how is this any different from changing > > the high limit while we are inside the reclaim loop? > > I believe reclaim loop rereads limits on each iteration, e.g. in > reclaim_high(), so it should always be enforcing the right limit. > > > > > > We also have exactly the same thing in memory_high_write(). > > > > > > So let's stop enforcing old limits if we already have a new ones. > > > > I do see any reasons why this would be harmful I just do not see why > > this is a real thing or why the new behavior is any better for racing > > updaters as those are not deterministic anyway. If you have any actual > > usecase then more details would really help to justify this change. > > > > The existing behavior makes some sense as it enforces the given limit > > deterministically. > > I don't have any actual problem, usecase or reproduce at hand, I only see a > potential problem: If the problem is only potential and also not very severe (it's not a crash or memory corruption or something like this), I'd say let's keep things as they are. Thanks!