From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail203.messagelabs.com (mail203.messagelabs.com [216.82.254.243]) by kanga.kvack.org (Postfix) with ESMTP id 18C886B0088 for ; Wed, 25 Nov 2009 18:08:09 -0500 (EST) Received: from spaceape10.eur.corp.google.com (spaceape10.eur.corp.google.com [172.28.16.144]) by smtp-out.google.com with ESMTP id nAPN86pK005581 for ; Wed, 25 Nov 2009 15:08:07 -0800 Received: from pxi11 (pxi11.prod.google.com [10.243.27.11]) by spaceape10.eur.corp.google.com with ESMTP id nAPN82Uj005363 for ; Wed, 25 Nov 2009 15:08:03 -0800 Received: by pxi11 with SMTP id 11so137209pxi.9 for ; Wed, 25 Nov 2009 15:08:02 -0800 (PST) Date: Wed, 25 Nov 2009 15:08:00 -0800 (PST) From: David Rientjes Subject: memcg: slab control Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org To: Balbir Singh , Pavel Emelyanov , KAMEZAWA Hiroyuki Cc: Suleiman Souhlal , Ying Han , linux-mm@kvack.org List-ID: Hi, I wanted to see what the current ideas are concerning kernel memory accounting as it relates to the memory controller. Eventually we'll want the ability to restrict cgroups to a hard slab limit. That'll require accounting to map slab allocations back to user tasks so that we can enforce a policy based on the cgroup's aggregated slab usage similiar to how the memory controller currently does for user memory. Is this currently being thought about within the memcg community? We'd like to start a discussion and get everybody's requirements and interests on the table and then become actively involved in the development of such a feature. Thanks. -- 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: email@kvack.org