From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tao Ma Subject: Re: [Lsf-pc] [LSF/MM ATTEND] Filesystems -- Btrfs, cgroups, Storage topics from Facebook Date: Tue, 31 Dec 2013 22:22:58 +0800 Message-ID: <52C2D342.8000606@tao.ma> References: <1388439412.16965.27.camel@ret> <20131231084927.GA29449@gmail.com> <20131231124535.GE11920@quack.suse.cz> <1388495991.16965.36.camel@ret> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-7 Content-Transfer-Encoding: 7bit Cc: "gnehzuil.liu@gmail.com" , "lsf-pc@lists.linux-foundation.org" , "linux-fsdevel@vger.kernel.org" To: Chris Mason , "jack@suse.cz" Return-path: Received: from server.coly.li ([162.144.45.48]:54360 "EHLO server.coly.li" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753740Ab3LaQPJ (ORCPT ); Tue, 31 Dec 2013 11:15:09 -0500 In-Reply-To: <1388495991.16965.36.camel@ret> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: Hi Chris, On 12/31/2013 09:19 PM, Chris Mason wrote: > On Tue, 2013-12-31 at 13:45 +0100, Jan Kara wrote: >> On Tue 31-12-13 16:49:27, Zheng Liu wrote: >>> Hi Chris, >>> >>> On Mon, Dec 30, 2013 at 09:36:20PM +0000, Chris Mason wrote: >>>> Hi everyone, >>>> >>>> I'd like to attend the LSF/MM conference this year. My current >>>> discussion points include: >>>> >>>> All things Btrfs! >>>> >>>> Adding cgroups for more filesystem resources, especially to limit the >>>> speed dirty pages are created. >>> >>> Interesting. If I remember correctly, IO-less dirty throttling has been >>> applied into upstream kernel, which can limit the speed that dirty pages >>> are created. Does it has any defect? >> It works as it should. But as Jeff points out, the throttling isn't >> cgroup aware. So it can happen that one memcg is full of dirty pages and >> reclaim has problems with reclaiming pages for it. I guess what Chris asks >> for is that we watch number of dirty pages in each memcg and throttle >> processes creating dirty pages in memcg which is close to its limit on >> dirty pages. > > Right, the ioless dirty throttling is fantastic, but it's based on the > BDI and you only get one of those per device. > > The current cgroup IO controller happens after we've decided to start > sending pages down. From a buffered write point of view, this is > already too late. If we delay the buffered IOs, the higher priority > tasks will just wait in balance_dirty_pages instead of waiting on the > drive. > > So I'd like to throttle the rate at which dirty pages are created, > preferably based on the rates currently calculated in the BDI of how > quickly the device is doing IO. This way we can limit dirty creation to > a percentage of the disk capacity during the current workload > (regardless of random vs buffered). Fengguang had already done some work on this, but it seems that the community does't have a consensus on where this control file should go. You can look at this link: https://lkml.org/lkml/2011/4/4/205 Thanks, Tao > > -chris > -- > To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html >