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

[C.Wehrmeyer]

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.