From patchwork Wed Mar 2 21:19:20 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vivek Goyal X-Patchwork-Id: 8485451 X-Patchwork-Delegate: snitzer@redhat.com Return-Path: X-Original-To: patchwork-dm-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id 66BD49F372 for ; Wed, 2 Mar 2016 21:22:28 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 852B320364 for ; Wed, 2 Mar 2016 21:22:27 +0000 (UTC) Received: from mx5-phx2.redhat.com (mx5-phx2.redhat.com [209.132.183.37]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 9C3382035D for ; Wed, 2 Mar 2016 21:22:26 +0000 (UTC) Received: from lists01.pubmisc.prod.ext.phx2.redhat.com (lists01.pubmisc.prod.ext.phx2.redhat.com [10.5.19.33]) by mx5-phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u22LJNb8043309; Wed, 2 Mar 2016 16:19:23 -0500 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by lists01.pubmisc.prod.ext.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id u22LJL7q018253 for ; Wed, 2 Mar 2016 16:19:21 -0500 Received: from horse.redhat.com (dhcp-25-239.bos.redhat.com [10.18.25.239]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u22LJK4b009043; Wed, 2 Mar 2016 16:19:21 -0500 Received: by horse.redhat.com (Postfix, from userid 10451) id 7DA05205FC8; Wed, 2 Mar 2016 16:19:20 -0500 (EST) Date: Wed, 2 Mar 2016 16:19:20 -0500 From: Vivek Goyal To: Chris Friesen Message-ID: <20160302211920.GH3476@redhat.com> References: <56CEB1BC.4000005@kyup.com> <20160225145314.GA20699@redhat.com> <20160302160649.GB29826@mtj.duckdns.org> <20160302175656.GA59991@redhat.com> <20160302191827.GC3476@redhat.com> <20160302201016.GE3476@redhat.com> <56D74E6A.9050708@windriver.com> <20160302210405.GG3476@redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20160302210405.GG3476@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 X-loop: dm-devel@redhat.com Cc: Jens Axboe , Mike Snitzer , SiteGround Operations , "linux-block@vger.kernel.org" , device-mapper development , Nikolay Borisov , Nikolay Borisov , Tejun Heo , "cgroups@vger.kernel.org" Subject: Re: [dm-devel] [PATCH] block: transfer source bio's cgroup tags to clone via bio_associate_blkcg() X-BeenThere: dm-devel@redhat.com X-Mailman-Version: 2.1.12 Precedence: junk List-Id: device-mapper development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dm-devel-bounces@redhat.com Errors-To: dm-devel-bounces@redhat.com X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Wed, Mar 02, 2016 at 04:04:05PM -0500, Vivek Goyal wrote: > On Wed, Mar 02, 2016 at 02:34:50PM -0600, Chris Friesen wrote: > > On 03/02/2016 02:10 PM, Vivek Goyal wrote: > > >On Wed, Mar 02, 2016 at 09:59:13PM +0200, Nikolay Borisov wrote: > > > > >We had similar issue with IO priority and it did not work reliably with > > >CFQ on underlying device when dm devices were sitting on top. > > > > > >If we really want to give it a try, I guess we will have to put cgroup > > >info of submitter early in bio at the time of bio creation even for all > > >kind of IO. Not sure if it is worth the effort. > > > > As it stands, imagine that you have a hypervisor node running many VMs (or > > containers), each of which is assigned a separate logical volume (possibly > > thin-provisioned) as its rootfs. > > > > Ideally we want the disk accesses by those VMs to be "fair" relative to each > > other, and we want to guarantee a certain amount of bandwidth for the host > > as well. > > > > Without this sort of feature, how can we accomplish that? > > As of now, you can't. I will try adding bio_associate_current() and see > if that along with Mike's patches gets you what you are looking for. > Can you try following also along with Mike's patch of carrying cgroup info over the clones. Mike, is it right place in dm layer to hook into. I think this will take care of bio based targets. Even after this I think there are still two issues. - bio_associate_current() assumes that submitter already has an io context otherwise does nothing. So in this case if container/VM process does not have io context, nothing will happen. - We will also need mechanism to carry io context information when we clone bio. Otherwise we will get the cgroup of the original process and io context of the dm thread (kind of odd). --- drivers/md/dm.c | 1 + 1 file changed, 1 insertion(+) Thanks Vivek -- dm-devel mailing list dm-devel@redhat.com https://www.redhat.com/mailman/listinfo/dm-devel Index: rhvgoyal-linux/drivers/md/dm.c =================================================================== --- rhvgoyal-linux.orig/drivers/md/dm.c 2016-03-02 19:19:12.301000000 +0000 +++ rhvgoyal-linux/drivers/md/dm.c 2016-03-02 21:11:01.357000000 +0000 @@ -1769,6 +1769,7 @@ static blk_qc_t dm_make_request(struct r generic_start_io_acct(rw, bio_sectors(bio), &dm_disk(md)->part0); + bio_associate_current(bio); /* if we're suspended, we have to queue this io for later */ if (unlikely(test_bit(DMF_BLOCK_IO_FOR_SUSPEND, &md->flags))) { dm_put_live_table(md, srcu_idx);