Re: [bug report?] unintuitive behavior when mapping over hugepage-backed PROT_NONE regions

[Lorenzo Stoakes <lorenzo.stoakes@oracle.com>]

On Sat, Feb 08, 2025 at 09:37:34AM -0800, Jörn Engel wrote:
> 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.

A _lot_ has changed. Try it again :)

>
> 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 lot of work has been done on reducing mmap_sem contention. Again, worth
another shot ;)

>
> 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.

This sounds like really ancient problems that no longer exist (as well as a lot
of FUD about THP at the time actually).

We tend to proactively go THP if we can these days.

>
>
> And yes, PROT_NONE/PROT_RW.  Sorry!

Haha no problem, just to clarify I understood you!

>
> Jörn
>
> --
> Every hour workers spend doing something else is an hour that they
> aren't doing their jobs.
> -- unknown
>