On Mon, May 9, 2011 at 3:18 AM, Johannes Weiner <hannes@xxxxxxxxxxx> wrote: > On Mon, May 09, 2011 at 04:10:47PM +0900, KAMEZAWA Hiroyuki wrote: >> On Sun, 8 May 2011 22:40:47 -0700 >> Ying Han <yinghan@xxxxxxxxxx> wrote: >> > 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? 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. 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. Thanks --Ying > Hannes > -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx 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