From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lord Glauber Costa of Sealand Subject: [ATTEND][LSF/MM TOPIC] the memory controller Date: Mon, 28 Jan 2013 12:11:41 +0400 Message-ID: <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 ([64.131.90.16]:53923 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751260Ab3A1ILU (ORCPT ); Mon, 28 Jan 2013 03:11:20 -0500 Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 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. * memcg/global oom handling: I believe that the OOM killer could be significantly improved to allow for more deterministic killing of tasks, specially in containers scenarios where memcg is heavily deployed. In some situations, a group encompasses a whole service, and under pressure, it would be better to shut down the group altogether with all its tasks, while in others it would be better to keep the current behavior of shooting down a single task. I also believe I will be able to help with general discussions concerning the memory controller in general, since pursuing ways to improve it - specially efficiency-wise - seems to be a recurring (and thankfully fruitful) topic. From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michel Lespinasse Subject: Re: [ATTEND][LSF/MM TOPIC] the memory controller Date: Fri, 8 Feb 2013 21:25:32 -0800 Message-ID: References: <510632BD.3010702@parallels.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Cc: lsf-pc@lists.linux-foundation.org, "linux-mm@kvack.org" , linux-fsdevel@vger.kernel.org To: Lord Glauber Costa of Sealand Return-path: In-Reply-To: <510632BD.3010702@parallels.com> Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org On Mon, Jan 28, 2013 at 12:11 AM, Lord Glauber Costa of Sealand wrote: > * memcg/global oom handling: I believe that the OOM killer could be > significantly improved to allow for more deterministic killing of tasks, > specially in containers scenarios where memcg is heavily deployed. In > some situations, a group encompasses a whole service, and under > pressure, it would be better to shut down the group altogether with all > its tasks, while in others it would be better to keep the current > behavior of shooting down a single task. We at Google have some OOM wish-list as well: - having an option to kill the entire cgroup when a contained task is selected to die; - recursive setting of OOM kill priorities in a cgroup hierarchy I am frankly not the best person to talk about this; however if this topic was selected I could plan for it and bring on a few notes :) -- Michel "Walken" Lespinasse A program is never fully debugged until the last user dies. -- 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 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/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx137.postini.com [74.125.245.137]) by kanga.kvack.org (Postfix) with SMTP id C40E36B0002 for ; Mon, 28 Jan 2013 03:11:20 -0500 (EST) Message-ID: <510632BD.3010702@parallels.com> Date: Mon, 28 Jan 2013 12:11:41 +0400 From: Lord Glauber Costa of Sealand MIME-Version: 1.0 Subject: [ATTEND][LSF/MM TOPIC] the memory controller Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: lsf-pc@lists.linux-foundation.org, "linux-mm@kvack.org" , linux-fsdevel@vger.kernel.org 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. * memcg/global oom handling: I believe that the OOM killer could be significantly improved to allow for more deterministic killing of tasks, specially in containers scenarios where memcg is heavily deployed. In some situations, a group encompasses a whole service, and under pressure, it would be better to shut down the group altogether with all its tasks, while in others it would be better to keep the current behavior of shooting down a single task. I also believe I will be able to help with general discussions concerning the memory controller in general, since pursuing ways to improve it - specially efficiency-wise - seems to be a recurring (and thankfully fruitful) topic. -- 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 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx121.postini.com [74.125.245.121]) by kanga.kvack.org (Postfix) with SMTP id DF7006B0027 for ; Wed, 10 Apr 2013 23:26:46 -0400 (EDT) Message-ID: <51662DA3.40003@parallels.com> Date: Thu, 11 Apr 2013 07:27:31 +0400 From: Glauber Costa MIME-Version: 1.0 Subject: Re: [ATTEND][LSF/MM TOPIC] the memory controller References: <510632BD.3010702@parallels.com> In-Reply-To: <510632BD.3010702@parallels.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org List-ID: To: lsf-pc@lists.linux-foundation.org, "linux-mm@kvack.org" , linux-fsdevel@vger.kernel.org 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/ -- 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