From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756202AbYKDVu2 (ORCPT ); Tue, 4 Nov 2008 16:50:28 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1753975AbYKDVuT (ORCPT ); Tue, 4 Nov 2008 16:50:19 -0500 Received: from smtp1.linux-foundation.org ([140.211.169.13]:60531 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753702AbYKDVuT (ORCPT ); Tue, 4 Nov 2008 16:50:19 -0500 Date: Tue, 4 Nov 2008 13:50:04 -0800 From: Andrew Morton To: Peter Zijlstra Cc: rientjes@google.com, cl@linux-foundation.org, npiggin@suse.de, menage@google.com, dfults@sgi.com, linux-kernel@vger.kernel.org, containers@lists.osdl.org Subject: Re: [patch 0/7] cpuset writeback throttling Message-Id: <20081104135004.f1717fcf.akpm@linux-foundation.org> In-Reply-To: <1225833710.7803.1993.camel@twins> References: <20081104124753.fb1dde5a.akpm@linux-foundation.org> <1225831988.7803.1939.camel@twins> <20081104131637.68fbe055.akpm@linux-foundation.org> <1225833710.7803.1993.camel@twins> X-Mailer: Sylpheed version 2.2.4 (GTK+ 2.8.20; i486-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 On Tue, 04 Nov 2008 22:21:50 +0100 Peter Zijlstra wrote: > On Tue, 2008-11-04 at 13:16 -0800, Andrew Morton wrote: > > On Tue, 04 Nov 2008 21:53:08 +0100 > > Peter Zijlstra wrote: > > > > > On Tue, 2008-11-04 at 12:47 -0800, Andrew Morton wrote: > > > > On Thu, 30 Oct 2008 12:23:10 -0700 (PDT) > > > > David Rientjes wrote: > > > > > > > > > This is the revised cpuset writeback throttling patchset > > > > > > > > I'm all confused about why this is a cpuset thing rather than a cgroups > > > > thing. What are the relationships here? > > > > > > > > I mean, writeback throttling _should_ operate upon a control group > > > > (more specifically: a memcg), yes? I guess you're assuming a 1:1 > > > > relationship here? > > > > > > I think the main reason is that we have per-node vmstats so the cpuset > > > extention is relatively easy. Whereas we do not currently maintain > > > vmstats on a cgroup level - although I imagine that could be remedied. > > > > It didn't look easy to me - it added a lot more code in places which are > > already wicked complex. > > > > I'm trying to understand where this is all coming from and what fits > > into where. Fiddling with a cpuset's mems_allowed for purposes of > > memory partitioning is all nasty 2007 technology, isn't it? Does a raw > > cpuset-based control such as this have a future? > > Yes, cpusets are making a come-back on the embedded multi-core Real-Time > side. Folks love to isolate stuff.. > > Not saying I really like it... > > Also, there seems to be talk about node aware pdflush from the > filesystems folks, not sure we need cpusets for that, but this does seem > to add some node information into it. Sorry, but I'm not seeing enough solid justification here for merging a fairly large amount of fairly tricksy code into core kernel. Code which, afaict, is heading in the opposite direction from where we've all been going for a year or two. What are the alternatives here? What do we need to do to make throttling a per-memcg thing? The patchset is badly misnamed, btw. It doesn't throttle writeback - in fact several people are working on IO bandwidth controllers and calling this thing "writeback throttling" risks confusion. What we're in fact throttling is rate-of-memory-dirtying. The last thing we want to throttle is writeback - we want it to go as fast as possible! Only I can't think of a suitable handy-dandy moniker for this concept.