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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 26 Nov 2013 16:55:43 +0400
From:	Vladimir Davydov <vdavydov@...allels.com>
To:	Johannes Weiner <hannes@...xchg.org>
CC:	<linux-kernel@...r.kernel.org>, <glommer@...nvz.org>,
	<mhocko@...e.cz>, <linux-mm@...ck.org>, <cgroups@...r.kernel.org>,
	<akpm@...ux-foundation.org>, <devel@...nvz.org>
Subject: Re: [Devel] [PATCH v11 00/15] kmemcg shrinkers

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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/