Re: [PATCH v2 0/4] memcg: Low-limit reclaim

[Greg Thelen <gthelen@google.com>]

[-- Attachment #1: Type: text/plain, Size: 1400 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 1707 bytes --]