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 19FF7C4167D for ; Wed, 8 Nov 2023 08:01:23 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id AB3208D00A5; Wed, 8 Nov 2023 03:01:22 -0500 (EST) Received: by kanga.kvack.org (Postfix, from userid 40) id A635D8D00A2; Wed, 8 Nov 2023 03:01:22 -0500 (EST) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 953108D00A5; Wed, 8 Nov 2023 03:01:22 -0500 (EST) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (smtprelay0012.hostedemail.com [216.40.44.12]) by kanga.kvack.org (Postfix) with ESMTP id 84F2F8D00A2 for ; Wed, 8 Nov 2023 03:01:22 -0500 (EST) Received: from smtpin14.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay10.hostedemail.com (Postfix) with ESMTP id 32966C0BDD for ; Wed, 8 Nov 2023 08:01:22 +0000 (UTC) X-FDA: 81434042004.14.5B6CD18 Received: from mail-ed1-f46.google.com (mail-ed1-f46.google.com [209.85.208.46]) by imf27.hostedemail.com (Postfix) with ESMTP id 639A440010 for ; Wed, 8 Nov 2023 08:01:20 +0000 (UTC) Authentication-Results: imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=HokcSWuo; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.46 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=1699430480; 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=HNi4fClCOjk3xdFXZ5yiVbLFHsXzEYt3ZKrZiBMxjyw=; b=BGO/l3sFHxi5nWLaZNIJ5r2QACGW3xMEFgOT0Itu9H8r8SLOsI8r3Jmh+Bi0qWrhdS3PPS +tOJETyy/c1tueDu514hE8cmBA3seRA3uV03AvKQ5MYJQ17/y0QCD2I5P+SVqgGoVOofuN JemHX+cjolHBRMDHa1D0El+nVgQGhhM= ARC-Authentication-Results: i=1; imf27.hostedemail.com; dkim=pass header.d=google.com header.s=20230601 header.b=HokcSWuo; dmarc=pass (policy=reject) header.from=google.com; spf=pass (imf27.hostedemail.com: domain of yosryahmed@google.com designates 209.85.208.46 as permitted sender) smtp.mailfrom=yosryahmed@google.com ARC-Seal: i=1; s=arc-20220608; d=hostedemail.com; t=1699430480; a=rsa-sha256; cv=none; b=nNQSbolIUfrko/i1TQJdDKoEo0XjPgPi+ze45IOzLFkfkkyXJIM3RWZtDWWvK/T0kMAm1U D25qZxxHq3DMAwSsmq4XKCGTOQMHiFjYWGx9rV7vzaLr1U3eoMqFL96HYxuXDUXt/Lhiro nYyNFIA4m17h5gIbsqtfNG8vcZHjrT0= Received: by mail-ed1-f46.google.com with SMTP id 4fb4d7f45d1cf-53e08e439c7so11266235a12.0 for ; Wed, 08 Nov 2023 00:01:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1699430479; x=1700035279; 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=HNi4fClCOjk3xdFXZ5yiVbLFHsXzEYt3ZKrZiBMxjyw=; b=HokcSWuo1PqW5wImtfU7Bwp5ajx0rJMtbRz2nEmM3b3U7iK3/fZwjQEL9v2a2fuf+O iWxs6dks1daNTd54CDmyMWDXgxiyCJTaK2CN3h1JXFdMkxizBA+LSx37eHHOv9IEL+u9 NwCSuj74EEUeE4GZ/WJL6qXgf6NIfYpVl52R/r1cWaIkAY6HXWcms1dT2dCjeN8jXv39 YYFH3d+HpEHk+2KxKCCkQHTux9u3uHsAMfRELl9sxdieE0l2g5t+aO5JNXLyJeElzMLR 52z2lcLMQ2g0ggMFRajLBiP4FRE+41XJE7dZRFWdb6vn1h8AIUgAbrwmUwJTSfsvTZKW kJtw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1699430479; x=1700035279; 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=HNi4fClCOjk3xdFXZ5yiVbLFHsXzEYt3ZKrZiBMxjyw=; b=dp2TB9VWCuuuOX5g4goV5SDV68eEGEfvOgFHoDXF5hKshWWeTl7s9jab3DvtZlUot0 0DiYalKrm3k39NpZqdcEUMapmeHWACc4XJ1P3wVFzL73TqoLz0ZRFPY4Oy6fxN0HCUcE mylA5IeYKjgVN09X8rINTnXG81XgBfG0EuL3qWCQ+/XGOe4pBWB/Wwn15QLzzfalujF9 RNW74bOndCSXJ8G0GLBS2pyx/mPWGvjG9lyhe5CMQDHWgb0cPN20jqYveJITv6UexJe+ 2AGr6b2qLHQpGCulG5MRkknHSA2jGrYML8oVHqpdP5vFBY5mUPTVScdbQ80WTgKdvV7f fF7A== X-Gm-Message-State: AOJu0YwQbGHJkw66QnbDFFuXUzNWtThV1qBJ8fRmI+WGinlIYC+A5qbh hjo9OkQRmqZ3/CXFwL8uhMZbx5bvkA0EaSwh0XEvQg== X-Google-Smtp-Source: AGHT+IF9zLVkQKgYnQFEJtbLFMGxGUHm/ggdeeQ390qH4xEE1KzKzMRdaKCiHY6k9DQcMexREYD80V4ZtE1hNp9Thbc= X-Received: by 2002:a17:907:60d4:b0:9ad:e298:a5d with SMTP id hv20-20020a17090760d400b009ade2980a5dmr789580ejc.19.1699430478750; Wed, 08 Nov 2023 00:01:18 -0800 (PST) MIME-Version: 1.0 References: <20231108065818.19932-1-link@vivo.com> In-Reply-To: <20231108065818.19932-1-link@vivo.com> From: Yosry Ahmed Date: Wed, 8 Nov 2023 00:00:39 -0800 Message-ID: Subject: Re: [RFC 0/4] Introduce unbalance proactive reclaim To: Huan Yang , Wei Xu , David Rientjes Cc: 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: 639A440010 X-Rspam-User: X-Rspamd-Server: rspam04 X-Stat-Signature: khfx89am96s8m4bhwqkx9yxcxxbutjy7 X-HE-Tag: 1699430480-240755 X-HE-Meta: U2FsdGVkX1+dolaI7XYOp/b/zDmgzmlDaoEBpYkg2F+FH4r7LoHN5Ar6Z8s9wG+RmE0sDgy/UUbYGfq2RxtevuPH4tmm+jOxWfoy9NkgJVsvVc5FFTFJfWPSbrVzOhPPoIk5uqY3oO105lyE2EOjGMPe2q8zR7aL0J/YpTS1CnTZIAyHThV4MSP0j9MYt3DP425q6DnxTijHK5vI3XDotqev/bnsiVIefGI8kpJ6SgksiPaUX6dXiWN8VTKFugngNm5M/esd2WGjPPThZxpllMZmrKR3QOfg3ChJYyFsaFCPvi/Y0HlYFImPJZ8+IPj1Hh+wcu44BXi/jGc97qSSb59c2AbU4pB4DzljziQs1VQyKGIcJk5Chm9/c31qXhYJr4BbU/Bsrrbw4QdkhdoSrczebVi6cxLibLB7Zzz16K5snzp4b2V+SwdzgvCTnDlwn2hcs61q4bAUmz7TU6dG9PmrV1fGF8gMcC3yR1opqljtDiIiPtrzzePFM9E9dyjbXk7vRrfagSiOa80BykITUk4up/0/dZiPVW68L6wZI0T/ROHjsZrs6Jjddaqj/g2VDshIKSV3P6Dk5AzDlZ/tTijC5XC1mof2VCUH8/M6AZKaqygUDCal2NsxE8vluyRd9K2xmtK9vCVr8VudJ2uGgiIJX8EPvEL5QR5lgzFFx56Td8RCnwrrpa1U5nRUm3LSHC0OOI0AS0ZbQ6fQVLOYXtDe/tZ9Nj0eSLexR7fBQ4lPzWlRQTlRgo3/b3VwP3NpnEQo5yPmFtlmL9nKcyRLubL6/O0FZmwTSGRUY3sLtnVE2XG0hvYme6YxhHgYYiS4T2f4xOxXCZzNX3Dn+Bu6mHeUK9Fxch3LdPqQkZpHzG5X6n9Ijdn4P1Rg7R+q9OCDtOMvU6x735cHG8PpQxkqFqbOQqxnBP+ZzqcCGTKf111+wQWwuGUwOuw1R3DWmPWMV5fj4YXcmA0PTlfsl/X mq3n76Jv 45Th8eryUYHK9x3RW3rupZbqofTSz5ATK9ChfWgZ0pqRNn7/a2pii62Xf83tjXlIY5JK6MRcaAbuigV1QOZqOJuGM4JM5f2JJQ2XpuCh9RuVGdtKaEhK9Aro8bJUsv2d1B/fXjo0qpZ0Mw6j/GRtwwP5tm3gwf8mGs+ME/tYd73MBY9Rj5Us4CTChVhqS6C8rCiMiHU1UU79SYp7nnDoYUNTk4ER3n+4Q9foCzXJe3qrUxRjoF94eECxCOSll/pF92L14m8l6E9jhFI1L3TOMYS4hOLl72ahBfDsxzLLHVfZeR2AzF7OaqcXaoTcZz21Nn+3ouDOrCfufdqwhVFtRL+VC3WCakScgo9UXVhf3+Ra2NPRJ1I2ppoHTQtqTiBP0snG/ETSAYZTPEK6kczVa0sBXxGNl1Gyt1diyEU5YxMHQc3JbjCKybFNU+w== 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: +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 frozen, > 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, users > can input special values to extremely reclaim specific pages. I proposed this a while back: https://lore.kernel.org/linux-mm/CAJD7tkbDpyoODveCsnaqBBMZEkDvshXJmNdbk51yK= SNgD7aGdg@mail.gmail.com/ 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 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.