Message-ID: <92fe0c31-b083-28c4-d306-da8a3cd891a3@redhat.com>
Date:   Tue, 23 Nov 2021 17:56:58 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.2.0
Subject: Re: [PATCH] mm: split thp synchronously on MADV_DONTNEED
Content-Language: en-US
To:     Shakeel Butt <shakeelb@google.com>
Cc:     "Kirill A . Shutemov" <kirill.shutemov@linux.intel.com>,
        Yang Shi <shy828301@gmail.com>, Zi Yan <ziy@nvidia.com>,
        Matthew Wilcox <willy@infradead.org>,
        Andrew Morton <akpm@linux-foundation.org>, linux-mm@kvack.org,
        linux-kernel@vger.kernel.org
References: <20211120201230.920082-1-shakeelb@google.com>
 <25b36a5c-5bbd-5423-0c67-05cd6c1432a7@redhat.com>
 <CALvZod5L1C1DV_DVs9O3xZm6CJnriunAoj89YLDdCp7ef5yBxA@mail.gmail.com>
 <1b30d06d-f9c0-1737-13e6-2d1a7d7b8507@redhat.com>
 <CALvZod5sFQbf3t_ZDW6ob+BqVtezn-c7i1UyOeev6Lwch96=7g@mail.gmail.com>
From:   David Hildenbrand <david@redhat.com>
Organization: Red Hat
In-Reply-To: <CALvZod5sFQbf3t_ZDW6ob+BqVtezn-c7i1UyOeev6Lwch96=7g@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

>> I do wonder which purpose the deferred split serves nowadays at all.
>> Fortunately, there is documentation: Documentation/vm/transhuge.rst:
>>
>> "
>> Unmapping part of THP (with munmap() or other way) is not going to free
>> memory immediately. Instead, we detect that a subpage of THP is not in
>> use in page_remove_rmap() and queue the THP for splitting if memory
>> pressure comes. Splitting will free up unused subpages.
>>
>> Splitting the page right away is not an option due to locking context in
>> the place where we can detect partial unmap. It also might be
>> counterproductive since in many cases partial unmap happens during
>> exit(2) if a THP crosses a VMA boundary.
>>
>> The function deferred_split_huge_page() is used to queue a page for
>> splitting. The splitting itself will happen when we get memory pressure
>> via shrinker interface.
>> "
>>
>> I do wonder which these locking contexts are exactly, and if we could
>> also do the same thing on ordinary munmap -- because I assume it can be
>> similarly problematic for some applications.
> 
> This is a good question regarding munmap. One main difference is
> munmap takes mmap_lock in write mode and usually performance critical
> applications avoid such operations.

Maybe we can extend it too most page zapping, if that makes things simpler.

> 
>> The "exit()" case might
>> indeed be interesting, but I really do wonder if this is even observable
>> in actual number: I'm not so sure about the "many cases" but I might be
>> wrong, of course.
> 
> I am not worried about the exit(). The whole THP will get freed and be
> removed from the deferred list as well. Note that deferred list does
> not hold reference to the THP and has a hook in the THP destructor.

Yes, you're right. We'll run into the de-constructor either way.

-- 
Thanks,

David / dhildenb