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
