On Jun 3, 2014 4:10 AM, "Michal Hocko" <mhocko@suse.cz> wrote:
>
> On Wed 28-05-14 09:17:13, Greg Thelen wrote:
> [...]
> > My 2c...  The following works for my use cases:
> > 1) introduce memory.low_limit_in_bytes (default=0 thus no default change
> >    from older kernels)
> > 2) interested users will set low_limit_in_bytes to non-zero value.
> >    Memory protected by low limit should be as migratable/reclaimable as
> >    mlock memory.  If a zone full of mlock memory causes oom kills, then
> >    so should the low limit.
>
> Would fallback mode in overcommit or the corner case situation break
> your usecase?

Yes.  Fallback mode would break my use cases.  What is the corner case situation?  NUMA conflicts?  Low limit is a substitute for users mlocking memory.  So if mlocked memory has the same NUMA conflicts, then I see no problem with low limit having the same behavior.

From a user API perspective, I'm not clear on the difference between non-ooming (fallback) low limit and the existing soft limit interface.  If low limit is a "soft" (non ooming) limit then why not rework the existing soft limit interface and save the low limit for strict (ooming) behavior?  

Of course, Google can continue to tweak the soft limit or new low limit to provide an ooming guarantee rather than violating the limit.

PS: I currently have very limited connectivity so my responses will be delayed.