Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754712Ab1CLBLX (ORCPT ); Fri, 11 Mar 2011 20:11:23 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:34511 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752394Ab1CLBLU (ORCPT ); Fri, 11 Mar 2011 20:11:20 -0500 Date: Fri, 11 Mar 2011 17:10:06 -0800 From: Andrew Morton To: Greg Thelen Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org, containers@lists.osdl.org, linux-fsdevel@vger.kernel.org, Andrea Righi , Balbir Singh , KAMEZAWA Hiroyuki , Daisuke Nishimura , Minchan Kim , Johannes Weiner , Ciju Rajan K , David Rientjes , Wu Fengguang , Chad Talbott , Justin TerAvest , Vivek Goyal Subject: Re: [PATCH v6 0/9] memcg: per cgroup dirty page accounting Message-Id: <20110311171006.ec0d9c37.akpm@linux-foundation.org> In-Reply-To: <1299869011-26152-1-git-send-email-gthelen@google.com> References: <1299869011-26152-1-git-send-email-gthelen@google.com> X-Mailer: Sylpheed 3.0.2 (GTK+ 2.20.1; x86_64-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1495 Lines: 43 On Fri, 11 Mar 2011 10:43:22 -0800 Greg Thelen wrote: > > ... > > This patch set provides the ability for each cgroup to have independent dirty > page limits. Here, it would be helpful to describe the current kernel behaviour. And to explain what is wrong with it and why the patch set improves things! > > ... > > Known shortcomings (see the patch 1/9 update to Documentation/cgroups/memory.txt > for more details): > - When a cgroup dirty limit is exceeded, then bdi writeback is employed to > writeback dirty inodes. Bdi writeback considers inodes from any cgroup, not > just inodes contributing dirty pages to the cgroup exceeding its limit. This is a pretty large shortcoming, I suspect. Will it be addressed? There's a risk that a poorly (or maliciously) configured memcg could have a pretty large affect upon overall system behaviour. Would elevated premissions be needed to do this? We could just crawl the memcg's page LRU and bring things under control that way, couldn't we? That would fix it. What were the reasons for not doing this? > - A cgroup may exceed its dirty limit if the memory is dirtied by a process in a > different memcg. Please describe this scenario in (a lot) more detail? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/