From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jan Kara Subject: Re: [Lsf-pc] [LSF/MM ATTEND] Filesystems -- Btrfs, cgroups, Storage topics from Facebook Date: Fri, 3 Jan 2014 07:03:46 +0100 Message-ID: <20140103060346.GA31086@quack.suse.cz> References: <1388439412.16965.27.camel@ret> <20131231084927.GA29449@gmail.com> <20131231124535.GE11920@quack.suse.cz> <1388495991.16965.36.camel@ret> <52C2D342.8000606@tao.ma> <1388504116.24668.0.camel@ret.masoncoding.com> <20140102064659.GF11920@quack.suse.cz> <1388676106.24668.14.camel@ret.masoncoding.com> <20140102160102.GH11501@htj.dyndns.org> <20140102161406.GI11501@htj.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Chris Mason , "jack@suse.cz" , "vgoyal@redhat.com" , "lizefan@huawei.com" , "gnehzuil.liu@gmail.com" , "tm@tao.ma" , "lsf-pc@lists.linux-foundation.org" , "linux-fsdevel@vger.kernel.org" To: "tj@kernel.org" Return-path: Received: from cantor2.suse.de ([195.135.220.15]:54188 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751105AbaACGDw (ORCPT ); Fri, 3 Jan 2014 01:03:52 -0500 Content-Disposition: inline In-Reply-To: <20140102161406.GI11501@htj.dyndns.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu 02-01-14 11:14:06, tj@kernel.org wrote: > Hey, again. > > On Thu, Jan 02, 2014 at 11:01:02AM -0500, tj@kernel.org wrote: > > What we're missing is a way to make such split visible in the upper > > layers for writeback. It seems rather clear to me that that's the > > right way to approach the problem rather than implementing separate > > control for writebacks and somehow coordinate that with the rest. > > To clarify a bit. I think what we need to do is splitting bdi's for > each active blkcg (at least the part which is relevant to propagating > io pressure upwards). Well, the pressure is currently propagated by the fact that we block on request allocation while writing back stuff... So this would mean splitting bdi flusher workqueue per blkcg. > I really don't think a scheme where we try to somehow split bandwidth > number between two separate enforcing mechanisms is something we should > go after. Agreed. Honza -- Jan Kara SUSE Labs, CR