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:   Mon, 29 Aug 2022 12:02:12 +0200
From:   David Hildenbrand <david@...hat.com>
To:     Rik van Riel <riel@...riel.com>, alexlzhu@...com,
        linux-mm@...ck.org
Cc:     willy@...radead.org, hannes@...xchg.org, akpm@...ux-foundation.org,
        kernel-team@...com, linux-kernel@...r.kernel.org
Subject: Re: [RFC 2/3] mm: changes to split_huge_page() to free zero filled
 tail pages

On 26.08.22 23:18, Rik van Riel wrote:
> On Fri, 2022-08-26 at 12:18 +0200, David Hildenbrand wrote:
>> On 25.08.22 23:30, alexlzhu@...com wrote:
>>> From: Alexander Zhu <alexlzhu@...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. 
>>>
>>
>> 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?
>>
> Many systems do not run KSM, though, and even on the systems
> where it does, KSM only covers a subset of the memory in the
> system.

Right, however there seems to be a push from some folks to enable it
more widely.

> 
> I could see wanting to maybe consolidate the scanning between
> KSM and this thing at some point, if it could be done without
> too much complexity, but keeping this change to split_huge_page
> looks like it might make sense even when KSM is enabled, since
> it will get rid of the unnecessary memory much faster than KSM could.
> 
> Keeping a hundred MB of unnecessary memory around for longer
> would simply result in more THPs getting split up, and more
> memory pressure for a longer time than we need.

Right. I was wondering if we want to map the shared zeropage instead of
the "detected to be zero" page, similar to how KSM would do it. For
example, with userfaultfd there would be an observable difference.

(maybe that's already done in this patch set)

-- 
Thanks,

David / dhildenb