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 6D5ACC35FF1 for ; Wed, 19 Mar 2025 05:29:08 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 5981C280002; Wed, 19 Mar 2025 01:29:06 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 51F7E280001; Wed, 19 Mar 2025 01:29:06 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 3C0B7280002; Wed, 19 Mar 2025 01:29:06 -0400 (EDT) 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 1A5C3280001 for ; Wed, 19 Mar 2025 01:29:06 -0400 (EDT) Received: from smtpin16.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 21EA3C1885 for ; Wed, 19 Mar 2025 05:29:07 +0000 (UTC) X-FDA: 83237171934.16.0FD7D31 Received: from out-188.mta1.migadu.com (out-188.mta1.migadu.com [95.215.58.188]) by imf20.hostedemail.com (Postfix) with ESMTP id 6286C1C0003 for ; Wed, 19 Mar 2025 05:29:05 +0000 (UTC) Authentication-Results: imf20.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=S3dk0SM4; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf20.hostedemail.com: domain of yosry.ahmed@linux.dev designates 95.215.58.188 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1742362145; a=rsa-sha256; cv=none; b=TWtQ+RefgLj1zvKsk2XaRGgb36VzKFwNn13arF6tRk8B7Vjic6Eug6pfTbDhZBkMGZF8sZ VDrqKBEu4QfE1kd9ZAgZcnpI7cPvH2Of6DXfgX0kyhqHNpbxyHMn1VWzwuLj02Ek2ySk2u YLULDR4BJqMC4qByBGsfd+s9iuaGBrY= ARC-Authentication-Results: i=1; imf20.hostedemail.com; dkim=pass header.d=linux.dev header.s=key1 header.b=S3dk0SM4; dmarc=pass (policy=none) header.from=linux.dev; spf=pass (imf20.hostedemail.com: domain of yosry.ahmed@linux.dev designates 95.215.58.188 as permitted sender) smtp.mailfrom=yosry.ahmed@linux.dev ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1742362145; 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=h1qHZ/pFekDYRn8NY2h+S9aQP+6EvUKpO/TvC9MJrtQ=; b=pgzzefePG8QsjC2aBaiFdjWpQNlavkun49ZSq5d4JNSVjUABiDC6DjFEHb/k5JpYXbt5u9 MnIgIUVbkVS0v1H4RMqsWCZ4GuYBVkrZXeKQJBq7kwIX1eyDvq0jvOgFihvoWu+rKHsMYW vDSNoqSb64CirRAV0pNA6rv9AlWziLY= Date: Wed, 19 Mar 2025 05:28:52 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linux.dev; s=key1; t=1742362143; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=h1qHZ/pFekDYRn8NY2h+S9aQP+6EvUKpO/TvC9MJrtQ=; b=S3dk0SM4hE5QEyo9hXVWbX5LiZYaMRWOwTLOXq35pZSeKz5bD0sA/5appBmCPNcgzFcvos 8gs3MGXREiygjxGO0ZxzxCRH/vNkRVSyA9gQ3sHL8enwfrsSr9P4BC8MWOwxEIb5+FKW64 BGe6o/EcqZA3HUfX9eLw8SgvpyVQHeY= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: Yosry Ahmed To: Zhongkun He Cc: akpm@linux-foundation.org, hannes@cmpxchg.org, yuzhao@google.com, mhocko@suse.com, muchun.song@linux.dev, linux-mm@kvack.org, linux-kernel@vger.kernel.org Subject: Re: [External] Re: [PATCH] mm: add swappiness=max arg to memory.reclaim for only anon reclaim Message-ID: References: <20250318135330.3358345-1-hezhongkun.hzk@bytedance.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Rspam-User: X-Rspamd-Queue-Id: 6286C1C0003 X-Stat-Signature: 7jaj5ato6xmu3piehnz56upo9upqhirr X-Rspamd-Server: rspam06 X-HE-Tag: 1742362145-622401 X-HE-Meta: U2FsdGVkX18W5nu2g/cJ2MLOfjJqSRdHRjQ/oobxKNSn2FpKDT+2f49o8XXsg23uS1W87wPoDddNWdcH31daxggZb55OdR3k6ewEpLJUJCaJad+zId5uFOiPy/Okx9TrrFfHq9xJxdAXJRKe5t4LGT32zimcCkGRr8gk10WVOXxHy/6klRxFwMSDZQwR4fkZBZHcBenRVsg2CHSR/UK8aBBV9OUE1arIf6tHJ+WbN/kTMIEjxLqZVkLHgIFV3S1hWy4apiWCniDLgyBBJg7eMraxLtuswupBQXwTbQUkIik9wlf80u0D2UgpBQdfQQNHfuWmyv7szYXdsu/ivNFYzze+8FgO+PSABNFX/WkW3i2ITwaTgWlGU4L5P0fyb1iVKpBnDsUg1n4BTfoHoxae66EzvnVabyR/t2nt8frUfYWH3KqPDApFzspH+kM+Vr/JrEgbY6PTh3ofhenUu3nDuhE0g6zl8y0CLxUih99YQguEamDwD8PtotJsGsUDiW5BF5yZvuG/fl9MnHp21n6AIB0ecbHfKWVto7o9SNuUtQd75ywwQlKA6LpMqjnCRYJetuIy+2UXIqjSCVzr2kE1CJYjG65VRUdx2lLEKfBHkNhjKl4VyOuonMRDy/GE4EiEPlbwwwVuYEtMMODMDgLAyU3pFgWnXJdTQOY9XNB1/D86nyP5bdFXGREo5vA7KcMf7QuxE0NaZA9h8IN2WYAtmKMJsDtspZksu5iKoVoW/d30zpvmz9GM35E7Rw3Gcv/Mgzm5G0LoUpohV9oK+3nAeZe4ORRfFknhBhoj/OBDCcZU6/q/YopYp3jfIcCe9rRc2n581jseicc= 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 19, 2025 at 10:34:54AM +0800, Zhongkun He wrote: > On Tue, Mar 18, 2025 at 10:10 PM Yosry Ahmed wrote: > > > > On Tue, Mar 18, 2025 at 09:53:30PM +0800, Zhongkun He wrote: > > > With this patch 'commit <68cd9050d871> ("mm: add swappiness= arg to > > > memory.reclaim")', we can submit an additional swappiness= argument > > > to memory.reclaim. It is very useful because we can dynamically adjust > > > the reclamation ratio based on the anonymous folios and file folios of > > > each cgroup. For example,when swappiness is set to 0, we only reclaim > > > from file folios. > > > > > > However,we have also encountered a new issue: when swappiness is set to > > > the MAX_SWAPPINESS, it may still only reclaim file folios. > > > > > > So, we hope to add a new arg 'swappiness=max' in memory.reclaim where > > > proactive memory reclaim only reclaims from anonymous folios when > > > swappiness is set to max. The swappiness semantics from a user > > > perspective remain unchanged. > > > > > > For example, something like this: > > > > > > echo "2M swappiness=max" > /sys/fs/cgroup/memory.reclaim > > > > > > will perform reclaim on the rootcg with a swappiness setting of 'max' (a > > > new mode) regardless of the file folios. Users have a more comprehensive > > > view of the application's memory distribution because there are many > > > metrics available. For example, if we find that a certain cgroup has a > > > large number of inactive anon folios, we can reclaim only those and skip > > > file folios, because with the zram/zswap, the IO tradeoff that > > > cache_trim_mode or other file first logic is making doesn't hold - > > > file refaults will cause IO, whereas anon decompression will not. > > > > > > With this patch, the swappiness argument of memory.reclaim has a new > > > mode 'max', means reclaiming just from anonymous folios both in traditional > > > LRU and MGLRU. > > > > Is MGLRU handled in this patch? > > Yes, The value of ONLY_ANON_RECLAIM_MODE is 201, and the MGLRU select the > evictable type like this: > > #define evictable_min_seq(min_seq, swappiness) \ > min((min_seq)[!(swappiness)], (min_seq)[(swappiness) <= MAX_SWAPPINESS]) > > #define for_each_evictable_type(type, swappiness) \ > for ((type) = !(swappiness); (type) <= ((swappiness) <= > MAX_SWAPPINESS); (type)++) > > if the swappiness=0, the type is LRU_GEN_FILE(1); > > if the swappiness=201 (>MAX_SWAPPINESS), > for ((type) = 0; (type) <= 0); (type)++) > The type is always LRU_GEN_ANON(0). Zhongkun, I see that you already sent a new version. Please wait until discussions on a patch are resolved before sending out newer versions, and allow more time for reviews in general. I think this is too subtle, and it's easy to miss. Looking at the MGLRU code it seems like there's a lot of swappiness <= MAX_SWAPPINESS checks, and I am not sure why these already exist given that swappiness should never exceed MAX_SWAPPINESS before this change. Are there other parts of the MGLRU code that are already using swappiness values > MAX_SWAPPINESS? Yu, could you help us making things clearer here? I would like to avoid relying on current implementation details that could easily be missed when making changes. Ideally we'd explicitly check for SWAPPINESS_ANON_ONLY.