[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 4 Apr 2012 10:36:04 -0500
From: Steve French <smfrench@...il.com>
To: Vivek Goyal <vgoyal@...hat.com>
Cc: Tejun Heo <tj@...nel.org>, ctalbott@...gle.com, rni@...gle.com,
andrea@...terlinux.com, containers@...ts.linux-foundation.org,
linux-kernel@...r.kernel.org, lsf@...ts.linux-foundation.org,
linux-mm@...ck.org, jmoyer@...hat.com, lizefan@...wei.com,
linux-fsdevel@...r.kernel.org, cgroups@...r.kernel.org
Subject: Re: [Lsf] [RFC] writeback and cgroup
On Wed, Apr 4, 2012 at 9:51 AM, Vivek Goyal <vgoyal@...hat.com> wrote:
> On Tue, Apr 03, 2012 at 11:36:55AM -0700, Tejun Heo wrote:
>
> Hi Tejun,
>
> Thanks for the RFC and looking into this issue. Few thoughts inline.
>
> [..]
>> IIUC, without cgroup, the current writeback code works more or less
>> like this. Throwing in cgroup doesn't really change the fundamental
>> design. Instead of a single pipe going down, we just have multiple
>> pipes to the same device, each of which should be treated separately.
>> Of course, a spinning disk can't be divided that easily and their
>> performance characteristics will be inter-dependent, but the place to
>> solve that problem is where the problem is, the block layer.
>
> How do you take care of thorottling IO to NFS case in this model? Current
> throttling logic is tied to block device and in case of NFS, there is no
> block device.
Similarly smb2 gets congestion info (number of "credits") returned from
the server on every response - but not sure why congestion
control is tied to the block device when this would create
problems for network file systems
--
Thanks,
Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists