Re: [patch v4] Soft limit rework

[Michal Hocko]

On Tue 04-06-13 21:57:56, Balbir Singh wrote:
> On Mon, Jun 3, 2013 at 3:48 PM, Michal Hocko <mhocko@xxxxxxx> wrote:
> > Hi,
> >
> > This is the fourth version of the patchset.
> >
> > Summary of versions:
> > The first version has been posted here: http://permalink.gmane.org/gmane.linux.kernel.mm/97973
> > (lkml wasn't CCed at the time so I cannot find it in lwn.net
> > archives). There were no major objections. The second version
> > has been posted here http://lwn.net/Articles/548191/ as a part
> > of a longer and spicier thread which started after LSF here:
> > https://lwn.net/Articles/548192/
> > Version number 3 has been posted here http://lwn.net/Articles/550409/
> > Johannes was worried about setups with thousands of memcgs and the
> > tree walk overhead for the soft reclaim pass without anybody in excess.
> >
> > Changes between RFC (aka V1) -> V2
> > As there were no major objections there were only some minor cleanups
> > since the last version and I have moved "memcg: Ignore soft limit until
> > it is explicitly specified" to the end of the series.
> >
> > Changes between V2 -> V3
> > No changes in the code since the last version. I have just rebased the
> > series on top of the current mmotm tree. The most controversial part
> > has been dropped (the last patch "memcg: Ignore soft limit until it is
> > explicitly specified") so there are no semantical changes to the soft
> > limit behavior. This makes this work mostly a code clean up and code
> > reorganization. Nevertheless, this is enough to make the soft limit work
> > more efficiently according to my testing and groups above the soft limit
> > are reclaimed much less as a result.
> >
> > Changes between V3->V4
> > Added some Reviewed-bys but the biggest change comes from Johannes
> > concern about the tree traversal overhead with a huge number of memcgs
> > (http://thread.gmane.org/gmane.linux.kernel.cgroups/7307/focus=100326)
> > and this version addresses this problem by augmenting the memcg tree
> > with the number of over soft limit children at each level of the
> > hierarchy. See more bellow.
> >
> > The basic idea is quite simple. Pull soft reclaim into shrink_zone in
> > the first step and get rid of the previous soft reclaim infrastructure.
> > shrink_zone is done in two passes now. First it tries to do the soft
> > limit reclaim and it falls back to reclaim-all mode if no group is over
> > the limit or no pages have been scanned. The second pass happens at the
> > same priority so the only time we waste is the memcg tree walk which
> > has been updated in the third step to have only negligible overhead.
> >
> 
> Hi, Michal
> 
> I've just looked at this (I am yet to review the series), but the
> intention of the changes do not read out clearly. Or may be I quite
> outdated on the subject :)

OK, let me summarize. The primary intention is to get rid of the current
soft reclaim infrastructure which basically bypasses the standard
reclaim and tight it directly into shrink_zone code. This also means
that the soft reclaim doesn't reclaim at priority 0 and that it is
active also for the targeted (aka limit) reclaim.

Does this help?
 
> Balbir

-- 
Michal Hocko
SUSE Labs
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/