From: "Jörn Engel" <joern@purestorage.com>
To: Lorenzo Stoakes <lorenzo.stoakes@oracle.com>
Cc: Uday Shankar <ushankar@purestorage.com>,
Muchun Song <muchun.song@linux.dev>,
Andrew Morton <akpm@linux-foundation.org>,
linux-mm@kvack.org, "Liam R. Howlett" <Liam.Howlett@oracle.com>,
Vlastimil Babka <vbabka@suse.cz>, Jann Horn <jannh@google.com>,
Oscar Salvador <osalvador@suse.de>
Subject: Re: [bug report?] unintuitive behavior when mapping over hugepage-backed PROT_NONE regions
Date: Sat, 8 Feb 2025 09:37:34 -0800 [thread overview]
Message-ID: <Z6eWXtwrcBjJ3M8U@cork> (raw)
In-Reply-To: <82afe852-4098-4eea-a646-37beab88604f@lucifer.local>
On Sat, Feb 08, 2025 at 04:02:47PM +0000, Lorenzo Stoakes wrote:
>
> To be clear, you won't get any kind of undefined behaviour (what that means
> wrt the kernel is not entirely clear - but if it were to mean as equivalent
> to the compiler sort 'anything might happen' - then no) or incomplete state.
Going off on that tangent, I think compiler folks completely abuse
undefined behavior. Historically it simply meant that you might get two
or more different (and well-defined) results, depending on which
specific hardware you ran on. Somehow that was reinterpreted as "I have
license to do whatever I want".
> I guess you mean PROT_NONE? :) For the case in the thread you would have to
> have mapped a hugetlb area over the PROT_NONE one without MAP_NORESERVE and
> with insufficiently reserved hugetlb pages, a combination which should be
> expected to possibly fail.
>
> If you perform an mprotect() to R/W the range, you will end up with a 'one
> and done' operation.
>
> I'd also suggest that hugetlb doesn't seem to fit a malloc library like to
> me, as you rely on reserved pages, rather wouldn't it make more sense to
> try to allocate memory that gets THP pages? You could MADV_COLLAPSE to try
> to make sure...
>
> However, if aligned correctly, we should automagically give you those.
We tried THP around 2012 and rejected it. The latency tail became a lot
longer and fatter. Various things have changed that might make THP less
bad today, but I am not aware of anyone reevaluating it.
I think the problem with THP was the mmap_sem. Given a heavily threaded
process, the mmap_sem tends to be the one dominant lock in the kernel.
A secondary problem might have been the background thread scanning for
pages that can be merged. Not sure about this part. We just disabled
THP and moved on to other problems.
And yes, PROT_NONE/PROT_RW. Sorry!
Jörn
--
Every hour workers spend doing something else is an hour that they
aren't doing their jobs.
-- unknown
next prev parent reply other threads:[~2025-02-08 17:37 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-06 6:18 Uday Shankar
2025-02-06 9:01 ` Oscar Salvador
2025-02-06 18:11 ` Jörn Engel
2025-02-06 18:54 ` Oscar Salvador
2025-02-07 10:29 ` Lorenzo Stoakes
2025-02-07 10:49 ` Vlastimil Babka
2025-02-07 12:33 ` Lorenzo Stoakes
2025-02-06 19:44 ` Uday Shankar
2025-02-07 13:12 ` Lorenzo Stoakes
2025-02-07 19:35 ` Jörn Engel
2025-02-08 16:02 ` Lorenzo Stoakes
2025-02-08 17:37 ` Jörn Engel [this message]
2025-02-08 17:40 ` Lorenzo Stoakes
2025-02-08 17:53 ` Jörn Engel
2025-02-08 18:00 ` Lorenzo Stoakes
2025-02-08 21:16 ` Jörn Engel
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=Z6eWXtwrcBjJ3M8U@cork \
--to=joern@purestorage.com \
--cc=Liam.Howlett@oracle.com \
--cc=akpm@linux-foundation.org \
--cc=jannh@google.com \
--cc=linux-mm@kvack.org \
--cc=lorenzo.stoakes@oracle.com \
--cc=muchun.song@linux.dev \
--cc=osalvador@suse.de \
--cc=ushankar@purestorage.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