[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1b400921-8bef-8073-10f9-a7cbb09cfefe@redhat.com>
Date: Tue, 23 Nov 2021 18:26:08 +0100
From: David Hildenbrand <david@...hat.com>
To: Shakeel Butt <shakeelb@...gle.com>
Cc: "Kirill A . Shutemov" <kirill.shutemov@...ux.intel.com>,
Yang Shi <shy828301@...il.com>, Zi Yan <ziy@...dia.com>,
Matthew Wilcox <willy@...radead.org>,
Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH] mm: split thp synchronously on MADV_DONTNEED
On 23.11.21 18:24, Shakeel Butt wrote:
> On Tue, Nov 23, 2021 at 9:20 AM David Hildenbrand <david@...hat.com> wrote:
>>
>> On 23.11.21 18:17, Shakeel Butt wrote:
>>> On Tue, Nov 23, 2021 at 8:57 AM David Hildenbrand <david@...hat.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
Powered by blists - more mailing lists