[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAF8kJuMKCu=Bf4K6RryFdGGgC+RhyanwaXc-ZGtURk7Wbckq6Q@mail.gmail.com>
Date: Fri, 15 Dec 2023 01:40:12 -0800
From: Chris Li <chrisl@...nel.org>
To: Fabian Deutsch <fdeutsch@...hat.com>
Cc: Yu Zhao <yuzhao@...gle.com>, Johannes Weiner <hannes@...xchg.org>,
Minchan Kim <minchan@...nel.org>, Nhat Pham <nphamcs@...il.com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>, "tj@...nel.org" <tj@...nel.org>,
"lizefan.x@...edance.com" <lizefan.x@...edance.com>,
"cerasuolodomenico@...il.com" <cerasuolodomenico@...il.com>,
"yosryahmed@...gle.com" <yosryahmed@...gle.com>, "sjenning@...hat.com" <sjenning@...hat.com>,
"ddstreet@...e.org" <ddstreet@...e.org>, "vitaly.wool@...sulko.com" <vitaly.wool@...sulko.com>,
"mhocko@...nel.org" <mhocko@...nel.org>, "roman.gushchin@...ux.dev" <roman.gushchin@...ux.dev>,
"shakeelb@...gle.com" <shakeelb@...gle.com>, "muchun.song@...ux.dev" <muchun.song@...ux.dev>,
"hughd@...gle.com" <hughd@...gle.com>, "corbet@....net" <corbet@....net>,
"konrad.wilk@...cle.com" <konrad.wilk@...cle.com>,
"senozhatsky@...omium.org" <senozhatsky@...omium.org>, "rppt@...nel.org" <rppt@...nel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>, "kernel-team@...a.com" <kernel-team@...a.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>, "david@...t.cz" <david@...t.cz>,
Kairui Song <kasong@...cent.com>, Zhongkun He <hezhongkun.hzk@...edance.com>
Subject: Re: [PATCH v6] zswap: memcontrol: implement zswap writeback disabling
On Thu, Dec 14, 2023 at 11:42 PM Fabian Deutsch <fdeutsch@...hat.com> wrote:.
> >
> > Just to clarify, the "node" you mean the "node" in kubernetes sense,
> > which is the whole machine. In the Linux kernel MM context, the node
> > often refers to the NUMA memory node, that is not what you mean here,
> > right?
>
> Correct, I was referring to a kubernetes node, not numa node.
>
> >
> >> - With todays node level swap, and setting memory.swap.max=0 for all cgroups allows you toachieve a similar behavior (only opt-in cgroups will get swap).
> >> - the above approach however will still have a shared swap backend for all cgroups.
> >
> > Yes, the "memory.swap.tires" idea is trying to allow cgroups to select
> > a subset of the swap backend in a specific order. It is still in the
> > early stage of discussion. If you have any suggestion or feedback in
> > that direction, I am looking forward to hearing that.
>
> Interesting. There have been concerns to leak confidential data accidentally when it's getting written to a swap device.
One common solution is to encrypt the data written to the device. If
someone gets hold of the swapped outed device without the key, they
can't get to the memory data without the key.
> The other less discussed item was QoS for swap io traffic.
>
> At a first glance it seems like tires could help with the second use-case.
The idea is that you can select the swap tiers list for each cgroup.
That way you can assign different swap QoS to different cgroup.
Chris
Powered by blists - more mailing lists