On Mon, May 09, 2011 at 09:51:43PM -0700, Ying Han wrote:

On Mon, May 9, 2011 at 3:18 AM, Johannes Weiner [off-list ref] wrote:

quoted

On Mon, May 09, 2011 at 04:10:47PM +0900, KAMEZAWA Hiroyuki wrote:

quoted

On Sun, 8 May 2011 22:40:47 -0700
Ying Han [off-list ref] wrote:

quoted

Using the
limit to calculate the wmarks is straight-forward since doing
background reclaim reduces the latency spikes under direct reclaim.
The direct reclaim is triggered while the usage is hitting the limit.

This is different from the "soft_limit" which is based on the usage
and we don't want to reinvent the soft_limit implementation.

Yes, this is a different feature.


The discussion here is how to make APIs for "shrink_to" and "shrink_over", ok ?

I think there are 3 candidates.

  1. using distance to limit.
     memory.shrink_to_distance
           - memory will be freed to 'limit - shrink_to_distance'.
     memory.shrink_over_distance
           - memory will be freed when usage > 'limit - shrink_over_distance'

     Pros.
      - Both of shrink_over and shirnk_to can be determined by users.
      - Can keep stable distance to limit even when limit is changed.
     Cons.
      - complicated and seems not natural.
      - hierarchy support will be very difficult.

  2. using bare value
     memory.shrink_to
           - memory will be freed to this 'shirnk_to'
     memory.shrink_from
           - memory will be freed when usage over this value.
     Pros.
      - Both of shrink_over and shrink)to can be determined by users.
      - easy to understand, straightforward.
      - hierarchy support will be easy.
     Cons.
      - The user may need to change this value when he changes the limit.


  3. using only 'shrink_to'
     memory.shrink_to
           - memory will be freed to this value when the usage goes over this vaue
             to some extent (determined by the system.)

     Pros.
      - easy interface.
      - hierarchy support will be easy.
      - bad configuration check is very easy.
     Cons.
      - The user may beed to change this value when he changes the limit.


Then, I now vote for 3 because hierarchy support is easiest and enough handy for
real use.

3. looks best to me as well.

What I am wondering, though: we already have a limit to push back
memcgs when we need memory, the soft limit.  The 'need for memory' is
currently defined as global memory pressure, which we know may be too
late.  The problem is not having no limit, the problem is that we want
to control the time of when this limit is enforced.  So instead of
adding another limit, could we instead add a knob like

       memory.force_async_soft_reclaim

that asynchroneously pushes back to the soft limit instead of having
another, separate limit to configure?

Pros:
- easy interface
- limit already existing
- hierarchy support already existing
- bad configuration check already existing
Cons:
- ?

Are we proposing to set the target of per-memcg background reclaim to
be the soft_limit?

Yes, if memory.force_async_soft_reclaim is set.

If so, i would highly doubt for that. The
logic of background reclaim is to start reclaiming memory before
reaching the hard_limit, and stops whence
it makes enough progress. The motivation is to reduce the times for
memcg hitting direct reclaim and that is quite different from
the design of soft_limit. The soft_limit is designed to serve the
over-commit environment where memory can be shared across memcgs
until the global memory pressure. There is no correlation between that
to the watermark based background reclaim.

Your whole argument for the knob so far has been that you want to use
it to proactively reduce memory usage, and I argued that it has
nothing to do with watermark reclaim.  This is exactly why I have been
fighting making the watermark configurable and abuse it for that.

Making the soft_limit as target for background reclaim will make extra
memory pressure when not necessary. So I don't have issue to have
the tunable later and set the watermark equal to the soft_limit, but
using it as alternative to the watermarks is not straight-forward to
me at
this point.

Please read my above proposal again, noone suggested to replace the
watermark with the soft limit.

1. The watermark is always in place, computed by the kernel alone, and
triggers background targetted reclaim when breached.

2. The soft limit is enforced as usual upon memory pressure.

3. In addition, the soft limit is enforced by background reclaim if
memory.force_async_soft_reclaim is set.

Thus, you can use 3. if you foresee memory pressure and want to
proactively push back a memcg to the soft limit.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>