linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Johannes Weiner <hannes@cmpxchg.org>
To: Shakeel Butt <shakeelb@google.com>
Cc: Dan Schatzberg <schatzberg.dan@gmail.com>,
	Roman Gushchin <roman.gushchin@linux.dev>,
	Yosry Ahmed <yosryahmed@google.com>, Huan Yang <link@vivo.com>,
	linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
	linux-mm@kvack.org, Michal Hocko <mhocko@kernel.org>,
	Muchun Song <muchun.song@linux.dev>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Hildenbrand <david@redhat.com>,
	Matthew Wilcox <willy@infradead.org>,
	Huang Ying <ying.huang@intel.com>,
	Kefeng Wang <wangkefeng.wang@huawei.com>,
	Peter Xu <peterx@redhat.com>,
	"Vishal Moola (Oracle)" <vishal.moola@gmail.com>,
	Yue Zhao <findns94@gmail.com>, Hugh Dickins <hughd@google.com>
Subject: Re: [PATCH 0/1] Add swappiness argument to memory.reclaim
Date: Thu, 30 Nov 2023 14:49:12 -0500	[thread overview]
Message-ID: <20231130194912.GB543908@cmpxchg.org> (raw)
In-Reply-To: <20231130184424.7sbez2ukaylerhy6@google.com>

On Thu, Nov 30, 2023 at 06:44:24PM +0000, Shakeel Butt wrote:
> On Thu, Nov 30, 2023 at 07:36:53AM -0800, Dan Schatzberg wrote:
> > (Sorry for the resend - forgot to cc the mailing lists)
> > 
> > This patch proposes augmenting the memory.reclaim interface with a
> > swappiness=<val> argument that overrides the swappiness value for that instance
> > of proactive reclaim.
> > 
> > Userspace proactive reclaimers use the memory.reclaim interface to trigger
> > reclaim. The memory.reclaim interface does not allow for any way to effect the
> > balance of file vs anon during proactive reclaim. The only approach is to adjust
> > the vm.swappiness setting. However, there are a few reasons we look to control
> > the balance of file vs anon during proactive reclaim, separately from reactive
> > reclaim:
> > 
> > * Swapout should be limited to manage SSD write endurance. In near-OOM
> 
> Is this about swapout to SSD only?
> 
> >   situations we are fine with lots of swap-out to avoid OOMs. As these are
> >   typically rare events, they have relatively little impact on write endurance.
> >   However, proactive reclaim runs continuously and so its impact on SSD write
> >   endurance is more significant. Therefore it is desireable to control swap-out
> >   for proactive reclaim separately from reactive reclaim
> 
> This is understandable but swapout to zswap should be fine, right?
> (Sorry I am not following the discussion on zswap patches from Nhat. Is
> the answer there?)

Memory compression alone would be fine, yes.

However, we don't use zswap in all cgroups. Lower priority things are
forced directly to disk. Some workloads compress poorly and also go
directly to disk for better memory efficiency. On such cgroups, it's
important for proactive reclaim to manage swap rates to avoid burning
out the flash.

Note that zswap also does SSD writes during writeback. I know this
doesn't apply to Google because of the ghost files, but we have SSD
swapfiles behind zswap. And this part will become more relevant with
Nhat's enhanced writeback patches.


  parent reply	other threads:[~2023-11-30 19:49 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-30 15:36 Dan Schatzberg
2023-11-30 15:36 ` [PATCH 1/1] mm: add swapiness= arg " Dan Schatzberg
2023-11-30 21:33   ` Andrew Morton
2023-11-30 21:46     ` Dan Schatzberg
2023-12-01  1:56   ` Huan Yang
2023-12-01  2:05     ` Yosry Ahmed
2023-12-01  2:13       ` Huan Yang
2023-12-01  2:17         ` Yosry Ahmed
2023-12-01  2:24           ` Huan Yang
2023-11-30 15:57 ` [PATCH 0/1] Add swappiness argument " Michal Hocko
2023-11-30 16:56   ` Johannes Weiner
2023-11-30 18:49     ` Shakeel Butt
2023-11-30 19:47     ` Dan Schatzberg
2023-11-30 20:30       ` Shakeel Butt
2023-11-30 21:37         ` Dan Schatzberg
2023-11-30 21:52           ` Shakeel Butt
2023-12-01  9:33     ` Michal Hocko
2023-12-01 15:49       ` Dan Schatzberg
2023-12-01 17:09       ` Johannes Weiner
2023-12-04 15:23         ` Michal Hocko
2023-12-05 16:19           ` Johannes Weiner
2023-12-07 18:57         ` Michal Koutný
2023-11-30 18:44 ` Shakeel Butt
2023-11-30 18:54   ` Matthew Wilcox
2023-11-30 19:39     ` Johannes Weiner
2023-11-30 19:49   ` Johannes Weiner [this message]
2023-11-30 19:50   ` Dan Schatzberg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20231130194912.GB543908@cmpxchg.org \
    --to=hannes@cmpxchg.org \
    --cc=akpm@linux-foundation.org \
    --cc=cgroups@vger.kernel.org \
    --cc=david@redhat.com \
    --cc=findns94@gmail.com \
    --cc=hughd@google.com \
    --cc=link@vivo.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=mhocko@kernel.org \
    --cc=muchun.song@linux.dev \
    --cc=peterx@redhat.com \
    --cc=roman.gushchin@linux.dev \
    --cc=schatzberg.dan@gmail.com \
    --cc=shakeelb@google.com \
    --cc=vishal.moola@gmail.com \
    --cc=wangkefeng.wang@huawei.com \
    --cc=willy@infradead.org \
    --cc=ying.huang@intel.com \
    --cc=yosryahmed@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox