From: Milan Broz <gmazyland@gmail.com>
To: Vlastimil Babka <vbabka@suse.cz>, Michal Hocko <mhocko@suse.com>
Cc: linux-mm@kvack.org,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Mikulas Patocka <mpatocka@redhat.com>
Subject: Re: Very slow unlockall()
Date: Mon, 1 Feb 2021 20:19:23 +0100 [thread overview]
Message-ID: <dfc3fe66-07ac-6aba-e10b-c940cdb01ec1@gmail.com> (raw)
In-Reply-To: <6eebb858-d517-b70d-9202-f4e84221ed89@suse.cz>
On 01/02/2021 19:55, Vlastimil Babka wrote:
> On 2/1/21 7:00 PM, Milan Broz wrote:
>> On 01/02/2021 14:08, Vlastimil Babka wrote:
>>> On 1/8/21 3:39 PM, Milan Broz wrote:
>>>> On 08/01/2021 14:41, Michal Hocko wrote:
>>>>> On Wed 06-01-21 16:20:15, Milan Broz wrote:
>>>>>> Hi,
>>>>>>
>>>>>> we use mlockall(MCL_CURRENT | MCL_FUTURE) / munlockall() in cryptsetup code
>>>>>> and someone tried to use it with hardened memory allocator library.
>>>>>>
>>>>>> Execution time was increased to extreme (minutes) and as we found, the problem
>>>>>> is in munlockall().
>>>>>>
>>>>>> Here is a plain reproducer for the core without any external code - it takes
>>>>>> unlocking on Fedora rawhide kernel more than 30 seconds!
>>>>>> I can reproduce it on 5.10 kernels and Linus' git.
>>>>>>
>>>>>> The reproducer below tries to mmap large amount memory with PROT_NONE (later never used).
>>>>>> The real code of course does something more useful but the problem is the same.
>>>>>>
>>>>>> #include <stdio.h>
>>>>>> #include <stdlib.h>
>>>>>> #include <fcntl.h>
>>>>>> #include <sys/mman.h>
>>>>>>
>>>>>> int main (int argc, char *argv[])
>>>>>> {
>>>>>> void *p = mmap(NULL, 1UL << 41, PROT_NONE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
>
> So, this is 2TB memory area, but PROT_NONE means it's never actually populated,
> although mlockall(MCL_CURRENT) should do that. Once you put PROT_READ |
> PROT_WRITE there, the mlockall() starts taking ages.
>
> So does that reflect your use case? munlockall() with large PROT_NONE areas? If
> so, munlock_vma_pages_range() is indeed not optimized for that, but I would
> expect such scenario to be uncommon, so better clarify first.
It is just a simple reproducer of the underlying problem, as suggested here
https://gitlab.com/cryptsetup/cryptsetup/-/issues/617#note_478342301
We use mlockall() in cryptsetup and with hardened malloc it slows down unlock significantly.
(For the real case problem please read the whole issue report above.)
m.
next prev parent reply other threads:[~2021-02-01 19:19 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-06 15:20 Very slow unlockall() Milan Broz
2021-01-08 13:41 ` Michal Hocko
2021-01-08 14:39 ` Milan Broz
2021-01-31 17:22 ` Milan Broz
2021-02-01 13:08 ` Vlastimil Babka
2021-02-01 18:00 ` Milan Broz
2021-02-01 18:55 ` Vlastimil Babka
2021-02-01 19:19 ` Milan Broz [this message]
2021-02-10 15:18 ` Vlastimil Babka
2021-02-10 16:57 ` Michal Hocko
2021-02-10 17:40 ` Michal Hocko
2021-02-11 5:21 ` Hugh Dickins
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dfc3fe66-07ac-6aba-e10b-c940cdb01ec1@gmail.com \
--to=gmazyland@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mhocko@suse.com \
--cc=mpatocka@redhat.com \
--cc=vbabka@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).