Re: [Devel] [PATCH v11 00/15] kmemcg shrinkers

[Vladimir Davydov]

On 11/26/2013 10:47 AM, Vladimir Davydov wrote:
> Hi,
>
> Thank you for the review. I agree with all your comments and I'll 
> resend the fixed version soon.
>
> If anyone still has something to say about the patchset, I'd be glad 
> to hear from them.
>
> On 11/25/2013 09:41 PM, Johannes Weiner wrote:
> > I ran out of steam reviewing these because there were too many things
> > that should be changed in the first couple patches.
> >
> > I realize this is frustrating to see these type of complaints in v11
> > of a patch series, but the review bandwidth was simply exceeded back
> > when Glauber submitted this along with the kmem accounting patches.  A
> > lot of the kmemcg commits themselves don't even have review tags or
> > acks, but it all got merged anyway, and the author has moved on to
> > different projects...
> >
> > Too much stuff slips past the only two people that have more than one
> > usecase on their agenda and are willing to maintain this code base -
> > which is in desparate need of rework and pushback against even more
> > drive-by feature dumps.  I have repeatedly asked to split the memcg
> > tree out of the memory tree to better deal with the vastly different
> > developmental stages of memcg and the rest of the mm code, to no
> > avail.  So I don't know what to do anymore, but this is not working.
> >
> > Thoughts?
>
> That's a pity, because w/o this patchset kmemcg is in fact useless. 
> Perhaps, it's worth trying to split it? (not sure if it'll help much 
> though since first 11 patches are rather essential :-( )

What do you think about splitting this set into two main series as follows:

1) Prepare vmscan to kmemcg-aware shrinkers; would include patches 1-7 
of this set.
2) Make fs shrinkers memcg-aware; would include patches 9-11 of this set

and leave other patches, which are rather for optimization/extending 
functionality, for future?

Thanks.
--
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/