On Mon, 30 Mar 2015, Eric B Munson wrote:

On Sun, 29 Mar 2015, Hugh Dickins wrote:

quoted

Eric, I apologize for bringing you in to the discussion, and then
ignoring your input.  I understand that you would like MAP_HUGETLB
to behave more understandably.  We can all agree that the existing
behavior is unsatisfying.  But it's many years too late now to 
change it around - and I suspect that a full exercise to do so would
actually discover some good reasons why the original choices were made.

No worries, my main concern was avoiding the confusion that led me down
the rabbit hole of compaction and mlock.  As long as the documentation,
man pages, and the code all agree I am satisfied.  I would have
preferred to make the code match the docs, but I understand that
changing the code now introduces a risk of breaking userspace.

It is charitable of you to assume that there were good reasons for the
original decision.  But as the author of the code in question, I suspect
the omission was one of my own inexperience.

No, you are both too modest and too arrogant :)

You were extending the existing hugetlbfs infrastructure to be
accessible through a MAP_HUGETLB interface.  You therefore inherited
the defects (some probably necessary, others perhaps not) of the
original hugetlbfs implementation, which is where this disagreeable
behaviour comes from.

If you were to ask for MAP_HUGETLB to behave differently from mapping
hugetlbfs here, I would shout no.  For a start, we'd have to add a
VM_HUGETLB2 flag so that each place that tests VM_HUGETLB (usually
through is_vm_hugetlb_page(vma) - sic) could decide how to behave
instead.

I for one have neither time nor inclination to write or review
any such patch.

Hugh