Re: [PATCH v4 2/3] mm: changes to split_huge_page() to free zero filled tail pages

[Yu Zhao <yuzhao@google.com>]

On Tue, Oct 18, 2022 at 9:42 PM <alexlzhu@fb.com> wrote:
>
> From: Alexander Zhu <alexlzhu@fb.com>
>
> Currently, when /sys/kernel/mm/transparent_hugepage/enabled=always is set
> there are a large number of transparent hugepages that are almost entirely
> zero filled.  This is mentioned in a number of previous patchsets
> including:
> https://lore.kernel.org/all/20210731063938.1391602-1-yuzhao@google.com/
> https://lore.kernel.org/all/
> 1635422215-99394-1-git-send-email-ningzhang@linux.alibaba.com/
>
> Currently, split_huge_page() does not have a way to identify zero filled
> pages within the THP. Thus these zero pages get remapped and continue to
> create memory waste. In this patch, we identify and free tail pages that
> are zero filled in split_huge_page(). In this way, we avoid mapping these
> pages back into page table entries and can free up unused memory within
> THPs. This is based off the previously mentioned patchset by Yu Zhao.

Hi Alex,

Generally the process [1] to follow is that you keep my patches
separate from yours, rather than squash them into one, e.g., [2].

[1] https://www.kernel.org/doc/html/latest/process/submitting-patches.html
[2] https://lore.kernel.org/linux-mm/cover.1665568707.git.christophe.leroy@csgroup.eu/

Also it's a courtesy to cc Ning, since his approach is (very) similar
to yours. Naturally he would wonder if you are reinventing the wheel,
so you'd have to address it in your cover letter.

> However, we chose to free anonymous zero tail pages whenever they are
> encountered instead of only on reclaim or migration.

What are cases that are not on reclaim or migration?

As I've explained off the mailing list, it's likely a bug if you
really have one. And I don't think you do. I'm currently under the
impression that you have a slab shrinker, and slab shrinkers are on
the reclaim path.

Thanks.