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 71F44C433F5 for ; Thu, 19 May 2022 05:18:02 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id EFB4B6B0072; Thu, 19 May 2022 01:18:01 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id EAB296B0073; Thu, 19 May 2022 01:18:01 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id D9A2D6B0074; Thu, 19 May 2022 01:18:01 -0400 (EDT) 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 CBFEE6B0072 for ; Thu, 19 May 2022 01:18:01 -0400 (EDT) Received: from smtpin25.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay09.hostedemail.com (Postfix) with ESMTP id 88F5432E74 for ; Thu, 19 May 2022 05:18:01 +0000 (UTC) X-FDA: 79481335962.25.A9822BD Received: from mail-vs1-f43.google.com (mail-vs1-f43.google.com [209.85.217.43]) by imf05.hostedemail.com (Postfix) with ESMTP id 014CC100005 for ; Thu, 19 May 2022 05:17:36 +0000 (UTC) Received: by mail-vs1-f43.google.com with SMTP id x8so4272592vsg.11 for ; Wed, 18 May 2022 22:18:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q48+ez61j/jJc9hrmvp2pUpDO4qTznT0ntaVS2nEhC4=; b=OvBLVdrh+T1hotfZBr5FRdvyEnFetZWbgUe1XbUWyNZLmsCrRt0HdE1I06lSN4SznT 1Q6XDBzV1HGI9cdpVycMxjHqU6NUY4rxesuPGaKRvvyAm7oAR85auBuAij40qJ4rUu1L GM2LozEBtZipNO5sprFfN8WZJ5/h+szw/MFJalQoA+DSuSoRqxV6Lash0LqNVXlWMQB9 FBu4bj8Kv6Z+4HOOrFPmLft+Ggse+QxMozAbh5AyMy0MDIfDMSIW5wtYllODKaAfNYz9 WfspntDhGDo1mpkvtICwP/TqFVU+UJ/rCNYtM/YUQbnBeDnyH6DpsRtfwflISbvv2TSh x6YQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=q48+ez61j/jJc9hrmvp2pUpDO4qTznT0ntaVS2nEhC4=; b=f4aKNHKECyBhBPUpPpisrZwoGrdbAO78t4hY6qFMnYLkTtIFRFzq0nGnioegU1Pg/J lQZmOZBLg3tggJSFn/MD58nFNRgSq4kw7DOyZEwluL7q98GpbEmbcB+97HbtBcs/7vnj sV+P6DM3mJc4BSDP/le7nA4CNbdU7cTHLn3FiSx2oJGv4AKNWSGUK74y/tC1v+fZ5F7F 6Es4Diz5xddMEY+NHnjCjpq5rpsISCLUPh3UYnKL7JvG68ABgt2XXyZX1YA8qXr3eP2u 6M1nBuhEfGDMInjlrLzRUYuqBGOa2VcVffbEOQ9dpK/6G6we47OtPzFrpyyHfsVEzZoI tUJQ== X-Gm-Message-State: AOAM533bXP5FFyaqEvx1VbTpDIFUnbBuji6pGyIcFAOFTmGT7HAOCMQn DA3R8V40TU7JeCsFh/oFlel14LB89fLopkuSJKWGBg== X-Google-Smtp-Source: ABdhPJwGpYaWUncieHZ4NrdI1CKS2jc4yn4TZmn8Su5QyzUD21BXav0o8YVUvbmTTdgMEgMMIlKyath6nAGOHYmELJk= X-Received: by 2002:a67:f8ce:0:b0:335:d520:ab7f with SMTP id c14-20020a67f8ce000000b00335d520ab7fmr1356503vsp.51.1652937480104; Wed, 18 May 2022 22:18:00 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Wei Xu Date: Wed, 18 May 2022 22:17:49 -0700 Message-ID: Subject: Re: [RFC] Add swappiness argument to memory.reclaim To: Roman Gushchin Cc: Yosry Ahmed , Johannes Weiner , Michal Hocko , Shakeel Butt , Andrew Morton , David Rientjes , Cgroups , Tejun Heo , Linux-MM , Yu Zhao , Greg Thelen , Chen Wandun Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 014CC100005 X-Stat-Signature: shwk8os9378cwzqst6cwjbcytpckb7w3 X-Rspam-User: Authentication-Results: imf05.hostedemail.com; dkim=pass header.d=google.com header.s=20210112 header.b=OvBLVdrh; spf=pass (imf05.hostedemail.com: domain of weixugc@google.com designates 209.85.217.43 as permitted sender) smtp.mailfrom=weixugc@google.com; dmarc=pass (policy=reject) header.from=google.com X-Rspamd-Server: rspam09 X-HE-Tag: 1652937456-493 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: On Tue, May 17, 2022 at 1:45 PM Roman Gushchin wrote: > > On Tue, May 17, 2022 at 01:11:13PM -0700, Yosry Ahmed wrote: > > On Tue, May 17, 2022 at 12:49 PM Roman Gushchin > > wrote: > > > > > > On Tue, May 17, 2022 at 11:13:10AM -0700, Yosry Ahmed wrote: > > > > On Tue, May 17, 2022 at 9:05 AM Roman Gushchin wrote: > > > > > > > > > > On Mon, May 16, 2022 at 03:29:42PM -0700, Yosry Ahmed wrote: > > > > > > The discussions on the patch series [1] to add memory.reclaim has > > > > > > shown that it is desirable to add an argument to control the type of > > > > > > memory being reclaimed by invoked proactive reclaim using > > > > > > memory.reclaim. > > > > > > > > > > > > I am proposing adding a swappiness optional argument to the interface. > > > > > > If set, it overwrites vm.swappiness and per-memcg swappiness. This > > > > > > provides a way to enforce user policy on a stateless per-reclaim > > > > > > basis. We can make policy decisions to perform reclaim differently for > > > > > > tasks of different app classes based on their individual QoS needs. It > > > > > > also helps for use cases when particularly page cache is high and we > > > > > > want to mainly hit that without swapping out. > > > > > > > > > > > > The interface would be something like this (utilizing the nested-keyed > > > > > > interface we documented earlier): > > > > > > > > > > > > $ echo "200M swappiness=30" > memory.reclaim > > > > > > > > > > What are the anticipated use cases except swappiness == 0 and > > > > > swappiness == system_default? > > > > > > > > > > IMO it's better to allow specifying the type of memory to reclaim, > > > > > e.g. type="file"/"anon"/"slab", it's a way more clear what to expect. > > > > > > > > I imagined swappiness would give user space flexibility to reclaim a > > > > ratio of file vs. anon as it sees fit based on app class or userspace > > > > policy, but I agree that the guarantees of swappiness are weak and we > > > > might want an explicit argument that directly controls the return > > > > value of get_scan_count() or whether or not we call shrink_slab(). My > > > > fear is that this interface may be less flexible, for example if we > > > > only want to avoid reclaiming file pages, but we are fine with anon or > > > > slab. > > > > Maybe in the future we will have a new type of memory to > > > > reclaim, does it get implicitly reclaimed when other types are > > > > specified or not? > > > > > > > > Maybe we can use one argument per type instead? E.g. > > > > $ echo "200M file=no anon=yes slab=yes" > memory.reclaim > > > > > > > > The default value would be "yes" for all types unless stated > > > > otherwise. This is also leaves room for future extensions (maybe > > > > file=clean to reclaim clean file pages only?). Interested to hear your > > > > thoughts on this! > > > > > > The question to answer is do you want the code which is determining > > > the balance of scanning be a part of the interface? > > > > > > If not, I'd stick with explicitly specifying a type of memory to scan > > > (and the "I don't care" mode, where you simply ask to reclaim X bytes). > > > > > > Otherwise you need to describe how the artificial memory pressure will > > > be distributed over different memory types. And with time it might > > > start being significantly different to what the generic reclaim code does, > > > because the reclaim path is free to do what's better, there are no > > > user-visible guarantees. > > > > My understanding is that your question is about the swappiness > > argument, and I agree it can get complicated. I am on board with > > explicitly specifying the type(s) to reclaim. I think an interface > > with one argument per type (whitelist/blacklist approach) could be > > more flexible in specifying multiple types per invocation (smaller > > race window between reading usages and writing to memory.reclaim), and > > has room for future extensions (e.g. file=clean). However, if you > > still think a type=file/anon/slab parameter is better we can also go > > with this. > > If you allow more than one type, how would you balance between them? > E.g. in your example: > $ echo "200M file=no anon=yes slab=yes" > memory.reclaim > How much slab and anonymous memory will be reclaimed? 100M and 100M? > Probably not (we don't balance slabs with other types of the memory). > And if not, the interface becomes very vague: all we can guarantee > is that *some* pressure will be applied on both anon and slab. > > My point is that the interface should have a deterministic behavior > and not rely on the current state of the memory pressure balancing > heuristic. It can be likely done in different ways, I don't have > a strong opinion here. I agree that the interface should have a clearly defined semantics and also like your proposal of just specifying a page type (e..g type=file/anon) to reclaim. > Thanks! From mboxrd@z Thu Jan 1 00:00:00 1970 From: Wei Xu Subject: Re: [RFC] Add swappiness argument to memory.reclaim Date: Wed, 18 May 2022 22:17:49 -0700 Message-ID: References: Mime-Version: 1.0 Return-path: DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=q48+ez61j/jJc9hrmvp2pUpDO4qTznT0ntaVS2nEhC4=; b=OvBLVdrh+T1hotfZBr5FRdvyEnFetZWbgUe1XbUWyNZLmsCrRt0HdE1I06lSN4SznT 1Q6XDBzV1HGI9cdpVycMxjHqU6NUY4rxesuPGaKRvvyAm7oAR85auBuAij40qJ4rUu1L GM2LozEBtZipNO5sprFfN8WZJ5/h+szw/MFJalQoA+DSuSoRqxV6Lash0LqNVXlWMQB9 FBu4bj8Kv6Z+4HOOrFPmLft+Ggse+QxMozAbh5AyMy0MDIfDMSIW5wtYllODKaAfNYz9 WfspntDhGDo1mpkvtICwP/TqFVU+UJ/rCNYtM/YUQbnBeDnyH6DpsRtfwflISbvv2TSh x6YQ== In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: Roman Gushchin Cc: Yosry Ahmed , Johannes Weiner , Michal Hocko , Shakeel Butt , Andrew Morton , David Rientjes , Cgroups , Tejun Heo , Linux-MM , Yu Zhao , Greg Thelen , Chen Wandun On Tue, May 17, 2022 at 1:45 PM Roman Gushchin wrote: > > On Tue, May 17, 2022 at 01:11:13PM -0700, Yosry Ahmed wrote: > > On Tue, May 17, 2022 at 12:49 PM Roman Gushchin > > wrote: > > > > > > On Tue, May 17, 2022 at 11:13:10AM -0700, Yosry Ahmed wrote: > > > > On Tue, May 17, 2022 at 9:05 AM Roman Gushchin wrote: > > > > > > > > > > On Mon, May 16, 2022 at 03:29:42PM -0700, Yosry Ahmed wrote: > > > > > > The discussions on the patch series [1] to add memory.reclaim has > > > > > > shown that it is desirable to add an argument to control the type of > > > > > > memory being reclaimed by invoked proactive reclaim using > > > > > > memory.reclaim. > > > > > > > > > > > > I am proposing adding a swappiness optional argument to the interface. > > > > > > If set, it overwrites vm.swappiness and per-memcg swappiness. This > > > > > > provides a way to enforce user policy on a stateless per-reclaim > > > > > > basis. We can make policy decisions to perform reclaim differently for > > > > > > tasks of different app classes based on their individual QoS needs. It > > > > > > also helps for use cases when particularly page cache is high and we > > > > > > want to mainly hit that without swapping out. > > > > > > > > > > > > The interface would be something like this (utilizing the nested-keyed > > > > > > interface we documented earlier): > > > > > > > > > > > > $ echo "200M swappiness=30" > memory.reclaim > > > > > > > > > > What are the anticipated use cases except swappiness == 0 and > > > > > swappiness == system_default? > > > > > > > > > > IMO it's better to allow specifying the type of memory to reclaim, > > > > > e.g. type="file"/"anon"/"slab", it's a way more clear what to expect. > > > > > > > > I imagined swappiness would give user space flexibility to reclaim a > > > > ratio of file vs. anon as it sees fit based on app class or userspace > > > > policy, but I agree that the guarantees of swappiness are weak and we > > > > might want an explicit argument that directly controls the return > > > > value of get_scan_count() or whether or not we call shrink_slab(). My > > > > fear is that this interface may be less flexible, for example if we > > > > only want to avoid reclaiming file pages, but we are fine with anon or > > > > slab. > > > > Maybe in the future we will have a new type of memory to > > > > reclaim, does it get implicitly reclaimed when other types are > > > > specified or not? > > > > > > > > Maybe we can use one argument per type instead? E.g. > > > > $ echo "200M file=no anon=yes slab=yes" > memory.reclaim > > > > > > > > The default value would be "yes" for all types unless stated > > > > otherwise. This is also leaves room for future extensions (maybe > > > > file=clean to reclaim clean file pages only?). Interested to hear your > > > > thoughts on this! > > > > > > The question to answer is do you want the code which is determining > > > the balance of scanning be a part of the interface? > > > > > > If not, I'd stick with explicitly specifying a type of memory to scan > > > (and the "I don't care" mode, where you simply ask to reclaim X bytes). > > > > > > Otherwise you need to describe how the artificial memory pressure will > > > be distributed over different memory types. And with time it might > > > start being significantly different to what the generic reclaim code does, > > > because the reclaim path is free to do what's better, there are no > > > user-visible guarantees. > > > > My understanding is that your question is about the swappiness > > argument, and I agree it can get complicated. I am on board with > > explicitly specifying the type(s) to reclaim. I think an interface > > with one argument per type (whitelist/blacklist approach) could be > > more flexible in specifying multiple types per invocation (smaller > > race window between reading usages and writing to memory.reclaim), and > > has room for future extensions (e.g. file=clean). However, if you > > still think a type=file/anon/slab parameter is better we can also go > > with this. > > If you allow more than one type, how would you balance between them? > E.g. in your example: > $ echo "200M file=no anon=yes slab=yes" > memory.reclaim > How much slab and anonymous memory will be reclaimed? 100M and 100M? > Probably not (we don't balance slabs with other types of the memory). > And if not, the interface becomes very vague: all we can guarantee > is that *some* pressure will be applied on both anon and slab. > > My point is that the interface should have a deterministic behavior > and not rely on the current state of the memory pressure balancing > heuristic. It can be likely done in different ways, I don't have > a strong opinion here. I agree that the interface should have a clearly defined semantics and also like your proposal of just specifying a page type (e..g type=file/anon) to reclaim. > Thanks!