From: Yu Zhao <yuzhao@google.com>
To: "Alex Zhu (Kernel)" <alexlzhu@fb.com>
Cc: Yang Shi <shy828301@gmail.com>, Rik van Riel <riel@fb.com>,
Kernel Team <Kernel-team@fb.com>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
"willy@infradead.org" <willy@infradead.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"akpm@linux-foundation.org" <akpm@linux-foundation.org>,
Ning Zhang <ningzhang@linux.alibaba.com>,
Miaohe Lin <linmiaohe@huawei.com>
Subject: Re: [PATCH v3] mm: add thp_utilization metrics to /proc/thp_utilization
Date: Wed, 10 Aug 2022 19:15:05 -0600 [thread overview]
Message-ID: <CAOUHufbD-9PpQ+kuD=-8z-ptsrprjyThpkFe+4_NtFnzAjDG9g@mail.gmail.com> (raw)
In-Reply-To: <DD679B3A-BDF7-4EBD-AAC2-A663057AC8E3@fb.com>
On Wed, Aug 10, 2022 at 6:00 PM Alex Zhu (Kernel) <alexlzhu@fb.com> wrote:
>
>
> > Which series are you talking about? I listed two series and they are
> > very different on the code level.
> >
>
> I was referring to the second patch: https://lore.kernel.org/all/1635422215-99394-1-git-send-email-ningzhang@linux.alibaba.com/.
You mean the second patch*set* or series, the link doesn't point to a
single patch :) "the second patch" could mean the second patch in
that series.
> This patchset adds the THP shrinking as part of shrink_lruvec in mm/vmscan.c. We create a new shrinker that shrinks THPs based off the results
> of the scanning implemented in this thp_utilization patch. We also do not have any of the additional knobs for controlling THP reclaim that the patchset above has. That seems unnecessary in the initial patch as shrinking THPs that are almost entirely zero pages should only improve performance.
>
> I believe the resulting implementation we have is simpler and easier to understand than the above patchset. By identifying and freeing underutilized THPs we hope to eventually deprecate madvise entirely and have THP always enabled.
>
> > The 2nd patch from the first series does exactly this.
> >
> >> but it’s worth discussing whether to free zero pages immediately or to add to lruvec to free eventually.
> >
> > And that patch can be omitted if the third link (a single patch, not a
> > series) is used, which makes the workflow "add to lruvec to free
> > eventually".
> >
> >> I believe the split_huge_page() changes could be valuable by as a patch by itself though. Will send that out shortly.
>
> Referring to this patch: https://lore.kernel.org/r/20210731063938.1391602-1-yuzhao@google.com/.
>
> We do indeed do something similar to patches 1 and 3. We may be able to make use of this instead, I’ll take a closer look.
Please do.
Based on what you said ("chose to free within split_huge_page()"), I
very much suspect you do something similar to patch 2 as well. IIRC,
that location is the best location to free subpages that only contain
zeros because it covers multiple scenarios.
next prev parent reply other threads:[~2022-08-11 1:15 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-05 18:40 alexlzhu
2022-08-05 18:50 ` Matthew Wilcox
2022-08-05 19:04 ` Rik van Riel
2022-08-05 19:24 ` Matthew Wilcox
2022-08-05 19:51 ` Alex Zhu (Kernel)
2022-08-08 17:55 ` Yang Shi
2022-08-08 18:35 ` Rik van Riel
2022-08-09 17:11 ` Yang Shi
2022-08-09 17:15 ` Alex Zhu (Kernel)
2022-08-09 23:35 ` Yu Zhao
2022-08-10 17:07 ` Yang Shi
2022-08-10 17:14 ` Alex Zhu (Kernel)
2022-08-10 17:54 ` Yu Zhao
2022-08-10 21:39 ` Alex Zhu (Kernel)
2022-08-10 21:56 ` Yu Zhao
2022-08-11 0:00 ` Alex Zhu (Kernel)
2022-08-11 1:15 ` Yu Zhao [this message]
2022-08-11 2:08 ` Alex Zhu (Kernel)
2022-08-11 19:20 ` Alex Zhu (Kernel)
2022-08-11 21:55 ` Yu Zhao
2022-08-11 22:12 ` Yang Shi
2022-08-11 22:59 ` Yu Zhao
2022-08-07 6:03 ` kernel test robot
2022-08-07 6:44 ` kernel test robot
2022-08-07 6:55 ` kernel test robot
2022-08-08 17:52 ` Yang Shi
2022-08-05 20:28 William Kucharski
2022-08-05 21:14 William Kucharski
2022-08-05 21:46 ` Alex Zhu (Kernel)
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='CAOUHufbD-9PpQ+kuD=-8z-ptsrprjyThpkFe+4_NtFnzAjDG9g@mail.gmail.com' \
--to=yuzhao@google.com \
--cc=Kernel-team@fb.com \
--cc=akpm@linux-foundation.org \
--cc=alexlzhu@fb.com \
--cc=linmiaohe@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=ningzhang@linux.alibaba.com \
--cc=riel@fb.com \
--cc=shy828301@gmail.com \
--cc=willy@infradead.org \
/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