On Mon 24-12-18 01:47:38, David Rientjes wrote:
> On Mon, 24 Dec 2018, Michal Hocko wrote:
>
> > > I'm not interested in having a 100 email thread about this when a clear
> > > and simple fix exists that actually doesn't break user code.
> >
> > You are breaking everybody who really wants to query MADV_NOHUGEPAGE
> > status by this flag. Is there anybody doing that? I don't know but
> > I guess we will find out one day. If the fix was a clear win then I
> > wouldn't say a word. But you are trading one regression which has a
> > proper fix proposed by another potential breakage which would be hard to
> > fix without breaking the former one. So this is a lose-lose situation.
> >
>
> No, smaps can be extended to specify anything else it needs to
> (exact PR_SET_THP_DISABLE usage vs MADV_NOHUGEPAGE). The VmFlag would
> specify either prior to your commit.
And that was an implementation detail of the PR_SET_THP_DISABLE at the
time. The documentation was quite clear
hg - huge page advise flag
nh - no-huge page advise flag
This is no different from people abusing VM_MIXEDMAP to detect DAX
mappings. We are not going to reintroduce VM_MIXEDMAP just to return smaps
consumers their undocumented side effect back. There is no promis on how
PR_SET_THP_DISABLE is implemented or will be implemented in the future.
But you know what, I simply have no interest discussing this with you
any further. Any discussion with you is simply pointless because you are
simply going to ignore any arguments and keep repeating your arguments
over and over until the other end simply gives up. Well done again.
--
Michal Hocko
SUSE Labs
