Thread (40 messages) 40 messages, 5 authors, 2018-11-20

Re: [RFC PATCH] mm, proc: report PR_SET_THP_DISABLE in proc

From: David Rientjes <rientjes@google.com>
Date: 2018-11-14 21:41:18
Also in: linux-mm, lkml

On Wed, 14 Nov 2018, Michal Hocko wrote:
quoted
quoted
quoted
Do you know of any other userspace except your usecase? Is there
anything fundamental that would prevent a proper API adoption for you?
Yes, it would require us to go back in time and build patched binaries. 
I read that as there is a fundamental problem to update existing
binaries. If that is the case then there surely is no way around it
and another sad page in the screwed up APIs book we provide.

But I was under impression that the SW stack which actually does the
monitoring is under your controll. Moreover I was under impression that
you do not use the current vanilla kernel so there is no need for an
immediate change on your end. It is trivial to come up with a backward
compatible way to check for the new flag (if it is not present then
fallback to vma flags).
The userspace had a single way to determine if thp had been disabled for a 
specific vma and that was broken with your commit.  We have since fixed 
it.  Modifying our software stack to start looking for some field 
somewhere else will not help anybody else that this has affected or will 
affect.  I'm interested in not breaking userspace, not trying a wait and 
see approach to see if anybody else complains once we start looking for 
some other field.  The risk outweighs the reward, it already broke us, and 
I'd prefer not to even open the possibility of breaking anybody else.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help