Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755058AbbF3PVO (ORCPT ); Tue, 30 Jun 2015 11:21:14 -0400 Received: from cantor2.suse.de ([195.135.220.15]:33871 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755042AbbF3PVL (ORCPT ); Tue, 30 Jun 2015 11:21:11 -0400 Date: Tue, 30 Jun 2015 17:21:05 +0200 From: Jan Kara To: Tejun Heo Cc: axboe@kernel.dk, linux-kernel@vger.kernel.org, jack@suse.cz, hch@infradead.org, hannes@cmpxchg.org, linux-fsdevel@vger.kernel.org, vgoyal@redhat.com, lizefan@huawei.com, cgroups@vger.kernel.org, linux-mm@kvack.org, mhocko@suse.cz, clm@fb.com, fengguang.wu@intel.com, david@fromorbit.com, gthelen@google.com, khlebnikov@yandex-team.ru Subject: Re: [PATCH 30/51] writeback: implement and use inode_congested() Message-ID: <20150630152105.GP7252@quack.suse.cz> References: <1432329245-5844-1-git-send-email-tj@kernel.org> <1432329245-5844-31-git-send-email-tj@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1432329245-5844-31-git-send-email-tj@kernel.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3040 Lines: 76 On Fri 22-05-15 17:13:44, Tejun Heo wrote: > In several places, bdi_congested() and its wrappers are used to > determine whether more IOs should be issued. With cgroup writeback > support, this question can't be answered solely based on the bdi > (backing_dev_info). It's dependent on whether the filesystem and bdi > support cgroup writeback and the blkcg the inode is associated with. > > This patch implements inode_congested() and its wrappers which take > @inode and determines the congestion state considering cgroup > writeback. The new functions replace bdi_*congested() calls in places > where the query is about specific inode and task. > > There are several filesystem users which also fit this criteria but > they should be updated when each filesystem implements cgroup > writeback support. > > v2: Now that a given inode is associated with only one wb, congestion > state can be determined independent from the asking task. Drop > @task. Spotted by Vivek. Also, converted to take @inode instead > of @mapping and renamed to inode_congested(). > > Signed-off-by: Tejun Heo > Cc: Jens Axboe > Cc: Jan Kara > Cc: Vivek Goyal > --- > fs/fs-writeback.c | 29 +++++++++++++++++++++++++++++ > include/linux/backing-dev.h | 22 ++++++++++++++++++++++ > mm/fadvise.c | 2 +- > mm/readahead.c | 2 +- > mm/vmscan.c | 11 +++++------ > 5 files changed, 58 insertions(+), 8 deletions(-) > > diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c > index 99a2440..7ec491b 100644 > --- a/fs/fs-writeback.c > +++ b/fs/fs-writeback.c > @@ -142,6 +142,35 @@ static void __wb_start_writeback(struct bdi_writeback *wb, long nr_pages, > wb_queue_work(wb, work); > } > > +#ifdef CONFIG_CGROUP_WRITEBACK > + > +/** > + * inode_congested - test whether an inode is congested > + * @inode: inode to test for congestion > + * @cong_bits: mask of WB_[a]sync_congested bits to test > + * > + * Tests whether @inode is congested. @cong_bits is the mask of congestion > + * bits to test and the return value is the mask of set bits. > + * > + * If cgroup writeback is enabled for @inode, the congestion state is > + * determined by whether the cgwb (cgroup bdi_writeback) for the blkcg > + * associated with @inode is congested; otherwise, the root wb's congestion > + * state is used. > + */ > +int inode_congested(struct inode *inode, int cong_bits) > +{ > + if (inode) { Hum, is there any point in supporting NULL inode with inode_congested()? That would look more like a programming bug than anything... Otherwise the patch looks good to me so you can add: Reviewed-by: Jan Kara Honza -- Jan Kara SUSE Labs, CR -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/