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 68B58C4332F for ; Wed, 8 Nov 2023 08:59:46 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 02D828D00B0; Wed, 8 Nov 2023 03:59:46 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id EF9238D00AD; Wed, 8 Nov 2023 03:59:45 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D74408D00B0; Wed, 8 Nov 2023 03:59:45 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0010.hostedemail.com [216.40.44.10]) by kanga.kvack.org (Postfix) with ESMTP id C5D428D00AD for ; Wed, 8 Nov 2023 03:59:45 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 9823880437 for ; Wed, 8 Nov 2023 08:59:45 +0000 (UTC) X-FDA: 81434189130.14.3635AE7 Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) by imf24.hostedemail.com (Postfix) with ESMTP id C90ED18000E for ; Wed, 8 Nov 2023 08:59:43 +0000 (UTC) Authentication-Results: imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=mRTmIZNZ; spf=pass (imf24.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.52 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=hostedemail.com; s=arc-20220608; t=1699433983; 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=Tor/EJdIpY1mQ+T8Qhv4C03xA4q/rVwv1DfBop2f0Do=; b=2ShVLj4g5UQYmpJDQTKl+QFEkK1bE58D9IlnHxUdnfBaB/2DzSWj6TJg3wAONhpxfBeM2N gzQeDu0ap/V6Cozm0IgAXRGl7Yv02E7OnWa6Kq5KOzt+/qEsuauOOT+0nIdWL8QOOjDt1U fSE7PtCpf7zcsnJ6Rm6H5XY/n5W4we8= ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699433983; a=rsa-sha256; cv=none; b=8QnFiFQtnopr2vWSnkWRVjPmOL4aN3K5T/lDiD+VE80bzXPjgRnYzcMvoQGQYFJW7bFr2b QNfEjDk1WSAGh38uCeWqL2Ny3Jq6hb4OsHXdFQ/IjDBYUIyKTydOOU3BAIUvRjad28mw1V d+pPBZv6WwsE2n6+cyzhW7k/ovfieMk= ARC-Authentication-Results: i=1; imf24.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=mRTmIZNZ; spf=pass (imf24.hostedemail.com: domain of yosryahmed@google.com designates 209.85.218.52 as permitted sender) smtp.mailfrom=yosryahmed@google.com; dmarc=pass (policy=reject) header.from=google.com Received: by mail-ej1-f52.google.com with SMTP id a640c23a62f3a-9e1fb7faa9dso304819066b.2 for ; Wed, 08 Nov 2023 00:59:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699433982; x=1700038782; 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=Tor/EJdIpY1mQ+T8Qhv4C03xA4q/rVwv1DfBop2f0Do=; b=mRTmIZNZd4uZjEH0K0syhBPWxzpuLDze5Nn40H/z+7Jj/N3nd0RV9yrVgFW31xC6DD jRyXulmSzubkCfPR53TgIZxgU6vq6krUfK+L/orjNb9apiH9vGeb3tsX2MKpFWrpApRu x9Nnxj9XV9k7/UHKpSMs2iz/5+SLBFvwbjsuErFphcqU7nMHSfzE6jE7pyoBTcLkFHPL TffMsg/3597J/o/ftPs+HsiAiTup0b/5nOFQCeNfyNtTun0T7OPfInohqERul+mg03Z3 KRp4wctaZ2rsDBdTkbGvp91pBXoSuiX3GLT25xFFoGWL2gn3pzX2KmJMospKK3llsCFQ K/cA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699433982; x=1700038782; 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=Tor/EJdIpY1mQ+T8Qhv4C03xA4q/rVwv1DfBop2f0Do=; b=DJng0FAtWlu6ntXlscnD8SZIZrAVJg4aRQIJtt8UwUx/X7xuIbhkSv0zYf8xj0KHvT eaXHpMRMOpnxf13R9hj1EFHLDqSwbH17rSjt3t261zZGsXm7W0PibZEKa4jEag99TAc/ OOJX6mUihQG6FA3r5rLQd/+lebqVZUkbW+e+1K+PCCQ77pcjfYxuka9djoLn2qyvD/+H 60zsq4NnLkxzf5/Y6wHrPl1omwM7gnAew3tJT0B8d0fdhY6JNYjmnuJY5Q1DGYJYOqJJ 9M8zXd4QHSMGVUk/OvBEG5aFa9247mJ8qNpLecVdTLm4Em/JmhWeFcC4Tq9H/nDjbmVh TNeA== X-Gm-Message-State: AOJu0Yx9MQaJWk6GoRxewQ3JrN0Z5R+XoLxQWH6FLHNYuhr0+AIHRl9g cGfWPCTa4nbbI5D5wCItQEzLKXMjtA/cnMr1y2xJiA== X-Google-Smtp-Source: AGHT+IGn6eGFsclyYzD50WFiPGxzCz+3fCLF0s6JgmmAuiqTby0HByPXoOE0rEbXVr+CVfr+KMHxOfjP0b/dgUSvGvM= X-Received: by 2002:a17:906:c103:b0:9c0:2897:1588 with SMTP id do3-20020a170906c10300b009c028971588mr790461ejc.17.1699433982110; Wed, 08 Nov 2023 00:59:42 -0800 (PST) MIME-Version: 1.0 References: <20231108065818.19932-1-link@vivo.com> <4c7db101-a34f-47ff-ba64-952516cc193a@vivo.com> In-Reply-To: <4c7db101-a34f-47ff-ba64-952516cc193a@vivo.com> From: Yosry Ahmed Date: Wed, 8 Nov 2023 00:59:02 -0800 Message-ID: Subject: Re: [RFC 0/4] Introduce unbalance proactive reclaim To: Huan Yang Cc: Wei Xu , David Rientjes , Tejun Heo , Zefan Li , Johannes Weiner , Jonathan Corbet , Michal Hocko , Roman Gushchin , Shakeel Butt , Muchun Song , Andrew Morton , David Hildenbrand , Matthew Wilcox , Huang Ying , 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: C90ED18000E X-Rspam-User: X-Stat-Signature: x76mjxnb9e9j7kttgn1jcfg98ugf3qes X-Rspamd-Server: rspam03 X-HE-Tag: 1699433983-655394 X-HE-Meta: U2FsdGVkX19E49nK1IMp7VDPjT58x7AFjU9DI5Mj4CkxAJTfgvdQuVqz2sKjKoIORV2uquLNYXE66kpaBV00CCMdv7PFo7b1Ct6qkL8q0nnQEa8JEuaOo6b5/PLuCatvwz5VVIiyzrc79xfBtkXvq6oDyOUe+g2voqozQzRM122OofqwOI13XA2Wgm3lrqJXPJjqCnmJp+ZKHADnqHkDhbC9hcM0tvevOiS5zthnbbM8pHOAq8QWbIu/KOix3FhQhRBr6+Pg4sSz6/5O2LWO4V9OcWqA0Al5nKsQQSffYLn+ejCwBNllg478Y31h4iL3HxcywO7MiDW/qSlLTFMIqDHLlstvkK9rpDGx4o4HodELZytWcyyzBiQlrwuCwsj/V/qQSpRx3c8cRBnLWnrp4NOXBUVkqiakQCMqVCohqNXhRDvihNsnCqMNuRi8P3cu3HOtjaKQrFNl807KrpO2VbEXAkVqYXf//EukdZi60Nq859aGT9f3+xTqjjl17RTHt/oYgI7R+Bl6Wyhdb4i9OZ5ybXIXwLHbwh1ECR7oYMv0btn9iwoAa9MQAEhGi6r59yUF7aeCejofNt49VCO3o3cqftEc7rIBgv8diTd7b+rm9QapwJUcQPxlFs3080aTU9GnNaTBoJ9czeVuPH1cXfdmPZgb6YsB26KHK3QVmJ2R4zpIJB4WerSTAV9Rd1HbG1v26nk5EAu/9N0F60vchaEfEZSKF7Kx4QZ+x8ItimgForvht30qQKH7xZWb3VkQMt+U2+0YeAxY8Rr+F0Q1sFvwVv0X6T7/GDjeRsil3jqLml/6zJVIwv2YkDk6/Pfe+eWtJqrNOXlGEjStHyILBjUShOfuglFwpfmBBpNrO64BM7ffQesK0C5IrGOyexvHnQYdmnmGvwl+RQGX4FHauxoIMzG+LxW6FjFdgF3LiD0AK0EmeKt0Ga6nh1PhUUXVx1XLdNt4c5RuU28Pwo4 Jxlg6PVJ lf9JQ1Jbq3bjZZ+ajoBJ7u9qLNDSML2WIJPsM6CXpunRx3D1C1blHadPY+ooGR+F3JEUkU3tQ++HivP5h4qkZJyHEaImytFlEzR5ef9ANJGFKAu78RWfclNvKCp900R+rL9OOlWw9RuHhoIMChfLkecxpXmwSk7CEShYppTR3rsgBf2+l3umL5Q4dUAbwIHyNegVDGNnQElHp01sxHr7P1acW5txVqpGaX2AzWCDMoZ6AC5+FQ6OfAFjcBXB7WZaHxx5HcPDfnfWTt6K+macG4jnqN3T66tqvLVYCn8cW20yONVqN4avCu65HT6f4iUmjdjnNtsx4kUg9KUHxLg9gJrKdSeIAs6J4UTUfBpwhEPEQCDdbNaDqvqujRbPrMz1O4XQUiMIK9sxDKDsOcXAXDrMldfFbd8Wx7v0tOYJKhzirLntABFiMPKgrNg== 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:26=E2=80=AFAM Huan Yang wrote: > > > =E5=9C=A8 2023/11/8 16:00, Yosry Ahmed =E5=86=99=E9=81=93: > > +Wei Xu +David Rientjes > > > > On Tue, Nov 7, 2023 at 10:59=E2=80=AFPM Huan Yang wrote= : > >> In some cases, we need to selectively reclaim file pages or anonymous > >> pages in an unbalanced manner. > >> > >> For example, when an application is pushed to the background and froze= n, > >> 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 pa= ges. > >> > >> 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, users > >> can input special values to extremely reclaim specific pages. > > I proposed this a while back: > > > > https://lore.kernel.org/linux-mm/CAJD7tkbDpyoODveCsnaqBBMZEkDvshXJmNdbk= 51yKSNgD7aGdg@mail.gmail.com/ > Well to know this, proactive reclaim single type is usefull in our > production too. > > > > The takeaway from the discussion was that swappiness is not the right > > way to do this. We can add separate arguments to specify types of > > memory to reclaim, as Roman suggested in that thread. I had some > > patches lying around to do that at some point, I can dig them up if > > that's helpful, but they are probably based on a very old kernel now, > > and before MGLRU landed. IIRC it wasn't very difficult, I think I > > added anon/file/shrinkers bits to struct scan_control and then plumbed > > them through to memory.reclaim. > > > >> 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) > > The type of interface here is nested-keyed, so if we add arguments > > they need to be in key=3Dvalue format. Example: > > > > echo 1G swappiness=3D200 > memory.reclaim > Yes, this is better. > > > > As I mentioned above though, I don't think swappiness is the right way > > of doing this. Also, without swappiness, I don't think there's a v1 vs > > v2 dilemma here. memory.reclaim can work as-is in cgroup v1, it just > > needs to be exposed there. > Cgroupv1 can't use memory.reclaim, so, how to exposed it? Reclaim this by > pass memcg's ID? That was mainly about the idea that cgroup v2 does not have per-memcg swappiness, so this proposal seems to be inclined towards v1, at least conceptually. Either way, we need to add memory.reclaim to the v1 files to get it to work on v1. Whether this is acceptable or not is up to the maintainers. I personally don't think it's a problem, it should work as-is for v1.