[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAHbLzkqpn2ExBJuPD8sYJrEDCUU9=FE3GFh8kL3Bmax0KytKPw@mail.gmail.com>
Date: Tue, 9 Aug 2022 10:11:31 -0700
From: Yang Shi <shy828301@...il.com>
To: Rik van Riel <riel@...com>
Cc: "Alex Zhu (Kernel)" <alexlzhu@...com>,
Kernel Team <Kernel-team@...com>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"willy@...radead.org" <willy@...radead.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>
Subject: Re: [PATCH v3] mm: add thp_utilization metrics to /proc/thp_utilization
On Mon, Aug 8, 2022 at 11:35 AM Rik van Riel <riel@...com> wrote:
>
> On Mon, 2022-08-08 at 10:55 -0700, Yang Shi wrote:
> >
> > On Fri, Aug 5, 2022 at 12:52 PM Alex Zhu (Kernel) <alexlzhu@...com>
> > wrote:
> > >
> > > Sounds good, I’ll move this to debugfs then. Will follow up with
> > > the shrinker code
> > > in another patch. The shrinker relies on this scanning thread to
> > > figure out which
> > > THPs to reclaim.
> >
> > I'm wondering whether you could reuse the THP deferred split shrinker
> > or not. It is already memcg aware.
> >
> I'm not convinced that will buy much, since there is
> very little code duplication between the two.
>
> Merging the two might also bring about another bit of
> extra complexity, due to the deferred split shrinker
> wanting to shrink every single THP on its "to split"
> list, while for Alex's shrinker we probably want to
> split just one (or a few) THPs at a time, depending on
> memory pressure.
OK, it is hard to tell what it looks like now. But the THPs on the
deferred split list may be on the "low utilization split" list too?
IIUC the major difference is to replace zero-filled subpage to special
zero page, so you implemented another THP split function to handle it?
Anyway the code should answer the most questions.
>
Powered by blists - more mailing lists