On Thu, May 26, 2011 at 2:05 AM, Johannes Weiner <hannes@xxxxxxxxxxx> wrote: > On Mon, May 16, 2011 at 05:18:20PM -0700, Andrew Morton wrote: >> On Mon, 16 May 2011 17:05:02 -0700 >> Ying Han <yinghan@xxxxxxxxxx> wrote: >> >> > On Mon, May 16, 2011 at 4:15 PM, Johannes Weiner <hannes@xxxxxxxxxxx> wrote: >> > >> > > On Mon, May 16, 2011 at 03:00:30PM -0700, Ying Han wrote: >> > > > This fixes the typo in the memory.stat including the following two >> > > > stats: >> > > > >> > > > $ cat /dev/cgroup/memory/A/memory.stat >> > > > total_soft_steal 0 >> > > > total_soft_scan 0 >> > > > >> > > > And change it to: >> > > > >> > > > $ cat /dev/cgroup/memory/A/memory.stat >> > > > total_soft_kswapd_steal 0 >> > > > total_soft_kswapd_scan 0 >> > > > >> > > > Signed-off-by: Ying Han <yinghan@xxxxxxxxxx> >> > > >> > > I am currently proposing and working on a scheme that makes the soft >> > > limit not only a factor for global memory pressure, but for >> > > hierarchical reclaim in general, to prefer child memcgs during reclaim >> > > that are in excess of their soft limit. >> > > >> > > Because this means prioritizing memcgs over one another, rather than >> > > having explicit soft limit reclaim runs, there is no natural counter >> > > for pages reclaimed due to the soft limit anymore. >> > > >> > > Thus, for the patch that introduces this counter: >> > > >> > > Nacked-by: Johannes Weiner <hannes@xxxxxxxxxxx> >> > > >> > >> > This patch is fixing a typo of the stats being integrated into mmotm. Does >> > it make sense to fix the >> > existing stats first while we are discussing other approaches? >> > >> >> It would be quite bad to add new userspace-visible stats and to then >> take them away again. >> >> But given that memcg-add-stats-to-monitor-soft_limit-reclaim.patch is >> queued for 2.6.39-rc1, we could proceed with that plan and then make >> sure that Johannes's changes are merged either prior to 2.6.40 or >> they are never merged at all. > > I am on it, but I don't think I can get them into shape and > rudimentally benchmarked until the merge window is closed. > > So far I found nothing that would invalidate the design or have > measurable impact on non-memcg systems. Then again, I suck at > constructing tests, and have only limited machinery available. > > If people are interested and would like to help out verifying the > changes, I can send an updated and documented version of the series > that should be easier to understand. Please do. I can help test it out. --Ying > >> Or we could just leave out the stats until we're sure. Not having them >> for a while is not as bad as adding them and then removing them. > > I am a bit unsure as to why there is a sudden rush with those > statistics now. > -- 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