Message-ID: <1b400921-8bef-8073-10f9-a7cbb09cfefe@redhat.com>
Date:   Tue, 23 Nov 2021 18:26:08 +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>
 <92fe0c31-b083-28c4-d306-da8a3cd891a3@redhat.com>
 <CALvZod4C1V6Gk96oMCMguaqChjggH0KH3KKcU1QOmjRG+QEAbQ@mail.gmail.com>
 <c61a6f30-ed62-7773-3371-981102f6804f@redhat.com>
 <CALvZod7xTfg5aeQC7-EaOZJ47Twb8CkoS6u4C=8+y+AX-NREVw@mail.gmail.com>
From:   David Hildenbrand <david@redhat.com>
Organization: Red Hat
In-Reply-To: <CALvZod7xTfg5aeQC7-EaOZJ47Twb8CkoS6u4C=8+y+AX-NREVw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Precedence: bulk

On 23.11.21 18:24, Shakeel Butt wrote:
> On Tue, Nov 23, 2021 at 9:20 AM David Hildenbrand <david@redhat.com> wrote:
>>
>> On 23.11.21 18:17, Shakeel Butt wrote:
>>> On Tue, Nov 23, 2021 at 8:57 AM David Hildenbrand <david@redhat.com> wrote:
>>>>
>>> [...]
>>>>>>
>>>>>> 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.
>>>>
>>>
>>> Do you mean doing sync THP split for most of page zapping functions
>>> (but only if that makes things simpler)?
>>>
>>
>> Yes -- if there are no downsides.
>>
> 
> I will try. At the moment the assumption of "Not null zap_details
> implies leave swap entries" is giving me a headache.

Not only you, did you stumble over

https://lkml.kernel.org/r/20211115134951.85286-1-peterx@redhat.com

already?

-- 
Thanks,

David / dhildenb