From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Chinner Subject: Re: [Lsf] IO less throttling and cgroup aware writeback (Was: Re: Preliminary Agenda and Activities for LSF) Date: Fri, 8 Apr 2011 09:47:17 +1000 Message-ID: <20110407234717.GF30279@dastard> References: <20110331141637.GA11139@redhat.com> <20110331222756.GC2904@dastard> <20110401171838.GD20986@redhat.com> <20110401214947.GE6957@dastard> <20110405131359.GA14239@redhat.com> <20110405225639.GB31057@dastard> <20110406230804.GJ31057@dastard> <20110407200437.GF27778@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Curt Wohlgemuth , Greg Thelen , James Bottomley , lsf@lists.linux-foundation.org, linux-fsdevel@vger.kernel.org To: Vivek Goyal Return-path: Received: from ipmail06.adl2.internode.on.net ([150.101.137.129]:25304 "EHLO ipmail06.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757159Ab1DGXrV (ORCPT ); Thu, 7 Apr 2011 19:47:21 -0400 Content-Disposition: inline In-Reply-To: <20110407200437.GF27778@redhat.com> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Apr 07, 2011 at 04:04:37PM -0400, Vivek Goyal wrote: > On Thu, Apr 07, 2011 at 09:08:04AM +1000, Dave Chinner wrote: > > [..] > > > At the very least, when a task is moved from one cgroup to another, > > > we've got a shared inode case. This probably won't happen more than > > > once for most tasks, but it will likely be common. > > > > That's not a shared case, that's a transfer of ownership. If the > > task changes groups, you have to charge all it's pages to the new > > group, right? Otherwise you've got a problem where a task that is > > not part of a specific cgroup is still somewhat controlled by it's > > previous cgroup. It would also still influence that previous group > > even though it's no longer a member. Not good for isolation purposes. > > > > And if you are transfering the state, moving the inode from the > > dirty list of one cgroup to another is trivial and avoids any need > > for the dirty state to be shared.... > > I am wondering how do you map a task to an inode. Multiple tasks in the > group might have written to same inode. Now which task owns it? That sounds like a completely broken configuration to me. If you are using cgroups for isolation, you simple do not share *anything* between them. Right now the only use case that has been presented for shared inodes is transfering a task from one cgroup to another. Why on earth would you do that if it is sharing resources with other tasks in the original cgroup? What use case does this represent, how often is it likely to happen, and who cares about it anyway? Let's not overly complicate things by making up requirements that nobody cares about.... Cheers, Dave. -- Dave Chinner david@fromorbit.com