From mboxrd@z Thu Jan 1 00:00:00 1970 From: Glauber Costa Subject: Re: [ATTEND][LSF/MM TOPIC] the memory controller Date: Thu, 11 Apr 2013 07:27:31 +0400 Message-ID: <51662DA3.40003@parallels.com> References: <510632BD.3010702@parallels.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit To: , "linux-mm@kvack.org" , Return-path: Received: from mx2.parallels.com ([199.115.105.18]:57315 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1765875Ab3DKD0q (ORCPT ); Wed, 10 Apr 2013 23:26:46 -0400 In-Reply-To: <510632BD.3010702@parallels.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 01/28/2013 12:11 PM, Lord Glauber Costa of Sealand wrote: > Hi, > > I've been working actively over the past year with the memory > controller, in particular its usage to track special bits of interest in > kernel memory land. As this work progress, I'd like to propose and > participate in the following discussions in the upcoming LSF/MM: > > * memcg kmem shrinking: as memory pressure appears within memcg, we need > to shrink some of the slab objects attributed to the group, maintaining > isolation as much as possible. The scheme also needs to allow for global > reclaim to keep working reliably, and of course, be memory efficient. > I have already posted some versions of it, that got quite some positive feedback(*), at least from the MM side. Shrinking is something that can be of interest for both mm and fs people, so maybe we could benefit for having some joint discussion about it * http://lwn.net/Articles/546472/