Re: PROBLEM: Remapping hugepages mappings causes kernel to return EINVAL

C.Wehrmeyer
2017-10-24T08:34:05Z

On 2017-10-24 10:12, Michal Hocko wrote:
> On Tue 24-10-17 09:41:46, C.Wehrmeyer wrote:
> [...]
>> 1. Provide mmap with some sort of flag (which would be redundant IMHO) in
>> order to churn out properly aligned pages (not transparent, but the current
>> MAP_HUGETLB flag isn't either).
>
> You can easily implement such a thing in userspace. In fact glibc has
> already done that for you.

That's not the point. The point is that it's not *transparent*. Let me
paraphrase your statements:

"Yes, you can have hugepages by just allocating things normally. THPs
will then be used - maybe. Even though you might know best how much
memory you actually require it requires you to fiddle with the mappings
in order to get complete hugepages coverage, because mmap does not
provide a mechanism for that. Or you can just live with your mappings
only being half-hugepaged. How is that not transparent?"

Unfortunately the ratio (512) is big enough that I'm not completely OK
with that. And in the distant future, when we all use 1-GiB pages, that
ratio becomes even bigger.

> [...]
> I think there is still some confusion here. Kernel will try to fault in
> THP pages on properly aligned addresses. So if you create a larger
> mapping than the THP size then you will get a THP (assuming the memory
> is not fragmented). It is just the unaligned addresses will get regular
> pages.

OK, I wasn't sure about that one as well - which is why I didn't dare to
lay hands on the kernel. It DOES support variable-sized-pages. That does
not change the fact, however, that when THPs are enabled mmap should
give userspace properly aligned pages exactly to avoid those smaller pages.