Re: [PATCH v10 00/35] kmemcg shrinkers

[Andrew Morton <akpm@linux-foundation.org>]

On Thu, 6 Jun 2013 09:51:03 +0400 Glauber Costa <glommer@parallels.com> wrote:

> On 06/06/2013 03:07 AM, Andrew Morton wrote:
> > On Mon,  3 Jun 2013 23:29:29 +0400 Glauber Costa <glommer@openvz.org> wrote:
> 
> > I haven't seen any show-stoppers yet so I guess I'll slam it all into
> > -next and cross fingers.  I would ask that the relevant developers set
> > aside a solid day to read and runtime test it all.  Realistically, it's
> > likely to take considerably more time that that.
> > 
> > I do expect that I'll drop the entire patchset again for the next
> > version, if only because the next version should withdraw all the
> > switch-random-code-to-xfs-coding-style changes...
> > 
> Ok, how do you want me to proceed ? Should I send a new series, or
> incremental? When exactly?
> 
> I do have at least two fixes to send that popped out this week: one of
> them for the drivers patch, since Kent complained about a malconversion
> of the bcache driver, and another one in the memcg page path.

Definitely a new series.  I tossed this series into -mm and -next so
that others can conveniently review and test it (hint).

> > 
> > I'm thinking that we should approach this in two stages: all the new
> > shrinker stuff separated from the memcg_kmem work.  So we merge
> > everything up to "shrinker: Kill old ->shrink API" and then continue to
> > work on the memcg things?
> > 
> 
> I agree with this, the shrinker part got a very thorough review from Mel
> recently. I do need to send you the fix for the bcache driver (or the
> whole thing, as you would prefer), and fix whatever comments you have.
> 
> Please note that as I have mentioned in the opening letter, I have two
> follow up patches for memcg (one of them allows us to use the shrinker
> infrastructure to reduce the value of kmem.limit, and the other one
> flushes the caches upon destruction). I haven't included in the series
> because the series is already huge, and I believe by including them,
> they would not get the review they deserve (by being new). Splitting it
> in two would allow me to include them in a smaller series.
> 
> I will go over your comments in a couple of hours. Please just advise me
> how would you like me to proceed with this logistically (new submission,
> fixes, for which patches, etc)

New everything, please.  There's no hurry - linux-next is going on
holidays for a week.

The shrinker stuff seems sensible and straightforward and I expect we
can proceed with that at the normal pace.  The memcg changes struck me
as being hairy as hell and I'd really like to see the other memcg
people go through it carefully.

Of course, "new series" doesn't give you an easily accessible tree to
target.  I could drop it all again to give you a clean shot at
tomorrow's -next?

--
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/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>