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 76B9AC4332F for ; Wed, 8 Nov 2023 09:01:11 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 166A48D00B2; Wed, 8 Nov 2023 04:01:11 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id 0F0DF8D00AD; Wed, 8 Nov 2023 04:01:11 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id EAC3D8D00B2; Wed, 8 Nov 2023 04:01:10 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0014.hostedemail.com [216.40.44.14]) by kanga.kvack.org (Postfix) with ESMTP id D5FFD8D00AD for ; Wed, 8 Nov 2023 04:01:10 -0500 (EST) Received: from smtpin22.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay08.hostedemail.com (Postfix) with ESMTP id B301A140C0B for ; Wed, 8 Nov 2023 09:01:10 +0000 (UTC) X-FDA: 81434192700.22.B5A616E Received: from mail-ej1-f41.google.com (mail-ej1-f41.google.com [209.85.218.41]) by imf15.hostedemail.com (Postfix) with ESMTP id AC250A0017 for ; Wed, 8 Nov 2023 09:01:08 +0000 (UTC) Authentication-Results: imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="FnbNu8/s"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.41 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699434068; 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=Ul5okWy9o9xZFKWypAudbUF2nSuflBiQ/Bzce/xS+LI=; b=zVuv2pWuHQ5fXsNvTw77UKJkC0b19iP7NSiW6zeQArQm+7ssEC5Aooe0ixzjigF88x9K5Q rir4JGUkXhIAD1fRs82gx0KRehSURWLKFUfrIrk/z/0RVPZWnjRPg3w3qnno30VdUsNdO6 XjFZYh5gZTMa+Hjqs19yr4Yx3gO2ZLw= ARC-Authentication-Results: i=1; imf15.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b="FnbNu8/s"; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf15.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.41 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699434068; a=rsa-sha256; cv=none; b=SgXcdvqpsGeqryZBfC8v+2geB8NPQXWIZxEgQwtbwURC3aqpR6aWdUQx6PHOBHjicEBSmP VVvrJt3lJ91FRZk3i/NmQQV1+/IbYKS03qDEAt0ze1i7NkHr0SzPoCn0F1EYA84MbcRqlh PHM1Az4yhdaOO9uShogQnUIXCAm4pKg= Received: by mail-ej1-f41.google.com with SMTP id a640c23a62f3a-9de7a43bd1aso609276266b.3 for ; Wed, 08 Nov 2023 01:01:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699434067; x=1700038867; darn=kvack.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=Ul5okWy9o9xZFKWypAudbUF2nSuflBiQ/Bzce/xS+LI=; b=FnbNu8/swO6dhMvTgCA/FAKYKx12HhacFPZ3Dz1rsL3b7GHMUhP38LLmVSlFXlM5UI ocrPRjfwWeNJnUBAudluzpT6V8TsUq1ZWWApHtYkRclavRVqMxnN+EeqEw/mFGMevzwa yfK/EzDwPocGogi42KnBCdzoFhrDk6aS4Cpsim0LPbxR82zojiqw4QC+ZApGFgoqlbu3 gPpIr5VlVwL3cHeh8R4SPkG8wGSxp/Xr5XsELkBQTldYG1JebCl+X++MuNOF+XGiO69N 8lwygaamFjiaeVmf4OYg5jjWqVipXProZTVmWdPSZu0bPNIPSpztY8RYhIR/+RvoD85z NxJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699434067; x=1700038867; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=Ul5okWy9o9xZFKWypAudbUF2nSuflBiQ/Bzce/xS+LI=; b=mHE35uJjDvNPG9+zPuE6nvdeE0htF2sJTUqmsGvoG5588SzSXLHlWHyrZNm1MonmcV jjSqcHraHZxtbOCNJwLIwivOwTxXF2aXohAJFRKs1H41Wwo45TDBCUpHcX+Fn/7JK6PD kbtnEV3re7toHRcU5+PjS2YzjVPMc04FI1zdhYrVpuUgC8ccEgotlxGZjCmrP8aKsQgv pRZ0X+eWGDxHMWCxszQpGyAx3U8vBRD0652XjQyLOQsKhGur0jGbUx54r9mJ/8wGAQfO vYr/Cx1ohh98KY/lyI/NllPHClcNPX6B7w9KqO/5K4Z+Ph9Ln6dg0eJEXjZhgEVD/3Rh QRJg== X-Gm-Message-State: AOJu0YzS382eyGM1rBvW2BV2aNma+k8vau/YRksKhMA09scNwgAvc/T6 BG4mSpeIjVeXb8bAurkw9GSvVJCIpL9ooHTpjZXI9w== X-Google-Smtp-Source: AGHT+IEZQFC5MQYN795SKbWm92b2+UaHLZXSe/S2e2/CpQ62gaOvDm5Nw9fOUkGFPY5jbdEA0C8GDl6/30L2c0Sxb/c= X-Received: by 2002:a17:907:2da5:b0:9c1:9b3a:4cd1 with SMTP id gt37-20020a1709072da500b009c19b3a4cd1mr866287ejc.3.1699434067155; Wed, 08 Nov 2023 01:01:07 -0800 (PST) MIME-Version: 1.0 References: <20231108065818.19932-1-link@vivo.com> <87v8ack889.fsf@yhuang6-desk2.ccr.corp.intel.com> <87r0l0k6o6.fsf@yhuang6-desk2.ccr.corp.intel.com> <4db7e55f-c6cb-4be2-89e1-339f6e32b85b@vivo.com> In-Reply-To: <4db7e55f-c6cb-4be2-89e1-339f6e32b85b@vivo.com> From: Yosry Ahmed Date: Wed, 8 Nov 2023 01:00:31 -0800 Message-ID: Subject: Re: [RFC 0/4] Introduce unbalance proactive reclaim To: Huan Yang Cc: "Huang, Ying" , Tejun Heo , Zefan Li , Johannes Weiner , Jonathan Corbet , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , David Hildenbrand , Matthew Wilcox , Kefeng Wang , Peter Xu , "Vishal Moola (Oracle)" , Liu Shixin , Hugh Dickins , cgroups@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mm@kvack.org, opensource.kernel@vivo.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: AC250A0017 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: bipfzwqsnb3xn9p8yfieemabr3bffgnu X-HE-Tag: 1699434068-936276 X-HE-Meta: U2FsdGVkX19sNiVpphBbYePSAmIHOLQht5cYbB2p/DPsli82/LTypgiW6Nu0zCzFRlA8wI/TwwaTQ5PPEeXD0YBLWGEdni/CJIofieBSfrIK3XPJontqFLZliNisWoU5AWk8AcELfozZVBb/WpjnQHLQPaTdD29nKXrAgfssEKCWjng6wATJ5Hhftf+yhho7jg8lzy4xRrYGF0oD6JfemOu/jlOihZUCVr5zkXYsKmlKSVa9S0s7xDGwifBDukDGRc36XKpKe5eVUKBZ8CsCYolY7Xn7YzLXBLz401ri5FHAb1+65SApJDCxeb7DkkkPNdrxOWqwcYghVylHGu8CiH2WSLQR/ogJ8g3TSWSd2ZfEsrkL4iHo/Ile5NjefhbI6tdXl59ml1VXOiqHDl6DZW183JYxSHjz8M0FY+cnbpSky4dVr5EtJlP7tKdSLJOqtNtWY2WHVoN6HoX8PpHjIDlgrwlfdbE0M/sRwHnm4NnzdcnvRxLdY02RJ8N3zxvaLL5r65lqBaetrIafH7aDPIJtWDDNEmd6A2Z/JzSA75gxLPNP+KEzMNJrY+TRJ8f8r116U1HxbopBviBeS6pAbJi9lagbudmtVzgSUdiaIhciIh3AXCXO+kQerIJGFOJnCXIlsIam26rp+4aMIK4qJB6yt1bYXsl0Cq8QWqsMD66xunl5s3tgIBq5fPXA0knMmttxyNOLnnjTCxP7MiODxTtvbRFr1pbYrn1iuCRFq1uEgsW8c4svq69QxzusOuBe3Rml8LVphwf4mJIHHgD8JLy1GMkKPLlJk31/0iL6+qeJrRE838uSCH506uuLQhEJwtsKBwdiavhKPQJtGW7S9U19kw++fxgCZBnRewBmKoJFGO4uXCt8U9TaZtMC24EJyIIqJ0swUa2POK6hUXi/gSeSdvXAE1of1y7KKWfyywWLFjFofwvRC9rqr+Pt0+CkycYXdmJUFSyvGRyZgtx Ru4R00DS PwJHIuPwk5KatdEskg+pC7uP38kswxxtivVGjkoChgBcM5BYkWANUNLVaE8Mw8b+4iWqPzsNcEWzIufvOkVB7QSoG4X09GKhKkOk6rAc6LQ3IjUjD91DVie88wnyQCbq0a+KGIkSLIK/3yysGmNbLJC7OOTXmv5g6fNX8V8bMrNMC+sxUbzdBpx4Tnu6tYvfHatZv/tPHePhNP1ltp7Df6vR8aEnX2QxEhLZRZUAUMIdeh6OpfrGcMvMWeo2hj18wvkT0NpdVdOTPESHUBFNT3f3XQ+6I1ITExeJf8AKU754i3z2aag6fN4TgRCTbuEnOVK5Q/2yt/+zm77rMlq+9hl6qpGrFPG5jHqNtMi+1RZfKf8MLCDNQbmhfP8lbkzvY3v4U 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, Nov 8, 2023 at 12:22=E2=80=AFAM Huan Yang wrote: > > > =E5=9C=A8 2023/11/8 16:14, Yosry Ahmed =E5=86=99=E9=81=93: > > On Wed, Nov 8, 2023 at 12:11=E2=80=AFAM Huang, Ying wrote: > >> Huan Yang writes: > >> > >>> HI Huang, Ying > >>> > >>> Thanks for reply. > >>> > >>> =E5=9C=A8 2023/11/8 15:35, Huang, Ying =E5=86=99=E9=81=93: > >>>> Huan Yang writes: > >>>> > >>>>> In some cases, we need to selectively reclaim file pages or anonymo= us > >>>>> pages in an unbalanced manner. > >>>>> > >>>>> For example, when an application is pushed to the background and fr= ozen, > >>>>> it may not be opened for a long time, and we can safely reclaim the > >>>>> application's anonymous pages, but we do not want to touch the file= pages. > >>>>> > >>>>> This patchset extends the proactive reclaim interface to achieve > >>>>> unbalanced reclamation. Users can control the reclamation tendency = by > >>>>> inputting swappiness under the original interface. Specifically, us= ers > >>>>> can input special values to extremely reclaim specific pages. > >>>> From mem_cgroup_swappiness(), cgroupv2 doesn't have per-cgroup > >>>> swappiness. So you need to add that firstly? > >>> Sorry for this mistake, we always work on cgroupv1, so, not notice > >>> this commit 4550c4e, thank your for point that. > >>> > >>> I see this commit comment that `that's a different discussion`, but, > >>> to implements this, I will try add. > >>> > >>>>> Example: > >>>>> echo "1G" 200 > memory.reclaim (only reclaim anon) > >>>>> echo "1G" 0 > memory.reclaim (only reclaim file) > >>>>> echo "1G" 1 > memory.reclaim (only reclaim file) > >>>>> > >>>>> Note that when performing unbalanced reclamation, the cgroup swappi= ness > >>>>> will be temporarily adjusted dynamically to the input value. Theref= ore, > >>>>> if the cgroup swappiness is further modified during runtime, there = may > >>>>> be some errors. > >>>> If cgroup swappiness will be adjusted temporarily, why not just chan= ge > >>>> it via a script before/after proactive reclaiming? > >>> IMO, this unbalance reclaim only takes effect for a single command, > >>> so if it is pre-set using a script, the judgment of the reclamation t= endency > >>> may become complicated. > >> If swappiness =3D=3D 0, then we will only reclaim file pages. If swap= piness > >> =3D=3D 200, then we may still reclaim file pages. So you need a way t= o > >> reclaim only anon pages? > >> > >> If so, can we use some special swappiness value to specify that? I > >> don't know whether use 200 will cause regression. If so, we may need > >> some other value, e.g. >=3D 65536. > > I don't think swappiness is the answer here. This has been discussed a > > while back, please see my response. As you mentioned, swappiness may > > be ignored by the kernel in some cases, and its behavior has > > historically changed before. > > For type base, reclaim can have direct tendencies as well. It's good. > But, what if > we only want to make small adjustments to the reclamation ratio? > Of course, sometimes swappiness may become ineffective. > Is there a real use case for this? I think it's difficult to reason about swappiness and make small adjustments to the file/anon ratio based on it. I'd prefer a more concrete implementation.