[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZWmoTa7MlD7h9FYm@tiehlicka>
Date: Fri, 1 Dec 2023 10:33:01 +0100
From: Michal Hocko <mhocko@...e.com>
To: Johannes Weiner <hannes@...xchg.org>
Cc: Dan Schatzberg <schatzberg.dan@...il.com>,
Roman Gushchin <roman.gushchin@...ux.dev>,
Yosry Ahmed <yosryahmed@...gle.com>, Huan Yang <link@...o.com>,
linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
linux-mm@...ck.org, Shakeel Butt <shakeelb@...gle.com>,
Muchun Song <muchun.song@...ux.dev>,
Andrew Morton <akpm@...ux-foundation.org>,
David Hildenbrand <david@...hat.com>,
Matthew Wilcox <willy@...radead.org>,
Huang Ying <ying.huang@...el.com>,
Kefeng Wang <wangkefeng.wang@...wei.com>,
Peter Xu <peterx@...hat.com>,
"Vishal Moola (Oracle)" <vishal.moola@...il.com>,
Yue Zhao <findns94@...il.com>, Hugh Dickins <hughd@...gle.com>
Subject: Re: [PATCH 0/1] Add swappiness argument to memory.reclaim
On Thu 30-11-23 11:56:42, Johannes Weiner wrote:
[...]
> So I wouldn't say it's merely a reclaim hint. It controls a very
> concrete and influential factor in VM decision making. And since the
> global swappiness is long-established ABI, I don't expect its meaning
> to change significantly any time soon.
As I've said I am more worried about potential future changes which
would modify existing, reduce or add more corner cases which would be
seen as a change of behavior from the user space POV. That means that we
would have to be really explicit about the fact that the reclaim is free
to override the swappiness provided by user. So essentially a best
effort interface without any actual guarantees. That surely makes it
harder to use. Is it still useable?
Btw. IIRC these concerns were part of the reason why memcg v2 doesn't
have swappiness interface. If we decide to export swappiness via
memory.reclaim interface does it mean we will do so on per-memcg level
as well?
--
Michal Hocko
SUSE Labs
Powered by blists - more mailing lists