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

[Rik van Riel <riel@surriel.com>]

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

On Mon, 2022-08-29 at 12:02 +0200, David Hildenbrand wrote:
> 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@fb.com wrote:
> > > > From: Alexander Zhu <alexlzhu@fb.com>
> > 
> > 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)
> 
The patch does not currently do that, but I suppose it could?

What exactly are the userfaultfd differences here, and how does
dropping 4kB pages break things vs. using the shared zeropage?

-- 
All Rights Reversed.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 484 bytes --]