On Tue, Oct 18, 2022 at 9:42 PM <alexlzhu@xxxxxx> wrote: > > From: Alexander Zhu <alexlzhu@xxxxxx> > > 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@xxxxxxxxxx/ > https://lore.kernel.org/all/ > 1635422215-99394-1-git-send-email-ningzhang@xxxxxxxxxxxxxxxxx/ > > 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@xxxxxxxxxx/ 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.
