linux-kernel - Re: [RFC 2/3] mm: changes to split_huge_page() to free zero filled tail pages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 26 Aug 2022 18:34:40 +0000
From:   "Alex Zhu (Kernel)" <alexlzhu@...com>
To:     David Hildenbrand <david@...hat.com>
CC:     "linux-mm@...ck.org" <linux-mm@...ck.org>,
        Matthew Wilcox <willy@...radead.org>,
        "hannes@...xchg.org" <hannes@...xchg.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "riel@...riel.com" <riel@...riel.com>,
        Kernel Team <Kernel-team@...com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [RFC 2/3] mm: changes to split_huge_page() to free zero filled
 tail pages



> On Aug 26, 2022, at 3:18 AM, David Hildenbrand <david@...hat.com> wrote:
> 
> !-------------------------------------------------------------------|
>  This Message Is From an External Sender
> 
> |-------------------------------------------------------------------!
> 
> On 25.08.22 23:30, alexlzhu@...com wrote:
>> From: Alexander Zhu <alexlzhu@...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@...ux.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.
>> However, we chose to free zero tail pages whenever they are encountered
>> instead of only on reclaim or migration. We also add a self test to verify
>> the RssAnon value to make sure zero pages are not remapped.
>> 
> 
> Isn't this to some degree splitting the THP (PMDs->PTEs + dissolve
> compound page) and then letting KSM replace the zero-filled page by the
> shared zeropage?
> 
> -- 
> Thanks,
> 
> David / dhildenb

AFAICT KSM may or may not replace the zero filled page with the shared zero page depending on whether the VMA is mergeable. Whether
or not the VMA is mergeable comes from madvise. Madvise only applies to certain memory regions. Here we have THP always enabled rather than on madvise, and the end goal is to deprecate madvise entirely.

These THPs would previously not have been split at all, as we could not identify which THPs were underutilized, and would thus
have just been memory waste when THP was always enabled. 

In split_huge_page() we chose the most straightforward approach to free (zap) the zero page immediately to get rid of the memory waste. It does not seem to me that KSM is necessary here.

Thanks,
Alex