Re: [PATCH] memcg: fix typo in the soft_limit stats.

[Ying Han <yinghan@google.com>]

On Thu, May 26, 2011 at 2:05 AM, Johannes Weiner <hannes@cmpxchg.org> 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@google.com> wrote:
>>
>> > On Mon, May 16, 2011 at 4:15 PM, Johannes Weiner <hannes@cmpxchg.org> 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@google.com>
>> > >
>> > > 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@cmpxchg.org>
>> > >
>> >
>> > 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@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>