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: - ? 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=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>