Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp337379imu; Tue, 27 Nov 2018 13:12:38 -0800 (PST) X-Google-Smtp-Source: AFSGD/WaVfKQR0RYKVHwK/vuKxxczOcH2hT8w5Se5whc0jHJOP0HAB9QC9gixAPhN0UoxR1fjdQz X-Received: by 2002:a63:5a57:: with SMTP id k23mr30555588pgm.5.1543353158788; Tue, 27 Nov 2018 13:12:38 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1543353158; cv=none; d=google.com; s=arc-20160816; b=jSDoGOAnWlFKFHV82HqRypCbXnSw8BWmcwiE9gBe9ixg88XM8ph1bdF1SvHRhhq9cT 5TJ7pmM7Fun4Nol/tVsz2Yeqw0Nu2dUX1eaMyQT/spJ7o17NZOE6Q/tNfcMK+UjgH735 PSiE2+zjc8saZUsp3I0Dg3MkahMFdhdIGYdvO8giHCAc8YgzEdSsJVQgdqD5xa83Ks8X dkb46P6cEpinsr7Ze7XgFUEv2TLTO51pUoQwC6NRR5WMGaqiIgOXggKAuyCjotY7TeW/ 4uzyACnQhBr0Wz43T7XYHs7NflgzHkCW9Xwvkix3EHLN3u303NtYFQNGW1quDBQwKlQX Ap2A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=ft4FysKjllP2Cb91bdlCvGAwT105IzF6SBB9loc5crw=; b=NQfVgar74CNjtwA7dkIh1rzv2SvmyEDMslKXzxbTNBzqIZxPWYr5Wmceslc91FS9On OSHYX48MAgQ/viI5l5BQdg8B7jOfaw/Hz4KOp/bM0kbpl6HW91YZNl9pyOSgxU8wUPxh KLc4E3Mr4dQOsjYwL6o1oux4xkRPB+AiAKF8zSTVEm1/OOZ33ogeqGwvw7IourSzheOT q1boyu9YwD7Jsz64QC80sqviKHDLGVgp4hIRxTmeyQTYsIYjKZm4md9b2rkT0plKVEcf Oo8t2QZdSOi+XpIncO1AU/orYi7EadhGKt5pv+FYtZlNDX1vApA6NqMq/sTjFB5zuJXv t4Uw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@toxicpanda-com.20150623.gappssmtp.com header.s=20150623 header.b=BoOePB6k; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id b8si5108631ple.185.2018.11.27.13.12.18; Tue, 27 Nov 2018 13:12:38 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@toxicpanda-com.20150623.gappssmtp.com header.s=20150623 header.b=BoOePB6k; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726762AbeK1IJO (ORCPT + 99 others); Wed, 28 Nov 2018 03:09:14 -0500 Received: from mail-qt1-f193.google.com ([209.85.160.193]:34072 "EHLO mail-qt1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726691AbeK1IJO (ORCPT ); Wed, 28 Nov 2018 03:09:14 -0500 Received: by mail-qt1-f193.google.com with SMTP id r14so23508173qtp.1 for ; Tue, 27 Nov 2018 13:10:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=toxicpanda-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=ft4FysKjllP2Cb91bdlCvGAwT105IzF6SBB9loc5crw=; b=BoOePB6kLkSnZtNKIPcQr3rKUW3BdTkn4WKLPB/o7AZYEO3KwwF2Gka33pvZ7Od4Wv crT2YUcWp7Ta37OtfbynZy2QqmmHy9apo0rTB3gdb1hAIZHVpaWUXZnHoaRS/S6PmGjA f/oCzd9ROZKMq81SX7yi6OKif3j5Nbg9xmyAMdhm3mbkjr8dH7FWx6hMNgi28l/JknAD bHlbjK/c1hdlqy6feSpzPFsvqD/JI24mBOYkL7hxXi6xPGK+5k4psVkSSwmCqb2sYPL5 QQn5jSk9cODOz3wwLcQ83t2Vvq1wPZj+2y3f6jVpO3pU7te0P1vfQJqFg2VdQYsy8EHg v7Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ft4FysKjllP2Cb91bdlCvGAwT105IzF6SBB9loc5crw=; b=gxDtejnJN5u2C1IcsaWwSkGn5ncPaG/lQ3mWqi2kjl1KuayB+nDATP9M9AuQ9Kvp6C U0UQ2oPSBddeT17Z4qjY6EqPdmECR79IkAYG9O9B+s2I2gdIuubPwPiO4CeAMT8p4ULx 49rz+ZKCTydxOFaPGHLvf6Jtgl2ix69Unilz1eCwYfhNbZNq18i1hH4lTp9WX+LIs9gX FEgtGQMOnMUAJ7qNIceXCTiWV66YXhwzs2YrkPzb2ydiTdMeOkWVHZ66cMv8CRkMeSyX pxuPs52V3GgPqNILtrQUecH47qhpz2juCwzXahKkTfNsYsfzkQytw/0emEazLfvt3t+7 MCsA== X-Gm-Message-State: AGRZ1gK7OveT7PTHe+CULVD3ucaFH5FEOg785ym2Umr6MwYPrYOuPj53 DX3+9UJi5HcggptlVT1nG3eGBA== X-Received: by 2002:ac8:7644:: with SMTP id i4mr32987833qtr.293.1543353002882; Tue, 27 Nov 2018 13:10:02 -0800 (PST) Received: from localhost ([2620:10d:c091:180::1:4c40]) by smtp.gmail.com with ESMTPSA id c77sm5121348qkh.82.2018.11.27.13.10.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Nov 2018 13:10:02 -0800 (PST) Date: Tue, 27 Nov 2018 16:10:01 -0500 From: Josef Bacik To: Dennis Zhou Cc: Jens Axboe , Tejun Heo , Johannes Weiner , Josef Bacik , kernel-team@fb.com, linux-block@vger.kernel.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 00/13 v4] block: always associate blkg and refcount cleanup Message-ID: <20181127210959.3c2yhp7citaxoqxm@macbook-pro-91.dhcp.thefacebook.com> References: <20181126211946.77067-1-dennis@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20181126211946.77067-1-dennis@kernel.org> User-Agent: NeoMutt/20180716 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Nov 26, 2018 at 04:19:33PM -0500, Dennis Zhou wrote: > Hi everyone, > > This is respin of v3 [1] with fixes for the errors reported in [2] and > [3]. v3 was reverted in [4]. > > The issue in [3] was that bio->bi_disk->queue and blkg->q were out > of sync. So when I changed blk_get_rl() to use blkg->q, the wrong queue > was returned and elevator from q->elevator->type threw a NPE. Note, with > v4.21, the old block stack was removed and so this patch was dropped. I > did backport this to v4.20 and verified this series does not encounter > the error. > > The biggest changes in v4 are when association occurs and clearly > defining the cases where association should happen. > 1. Association is now done when the device is set to keep blkg->q and > bio->bi_disk->queue in sync. > 2. When a bio is submitted directly to the device, it will not be > associated with a blkg. This is because a blkg represents the > relationship between a blkcg and a request_queue. Going directly to > the device means the request_queue may not exist meaning no blkg > will exist. > > The patch updating blk_get_rl() was dropped (v3 10/12). The patch to > always associate a blkg from v3 (v3 04/12) was fixed and split into > patches 0004 and 0005. 0011 is new removing bio_disassociate_task(). > > Summarizing the ideas of this series: > 1. Gracefully handle blkg failure to create by walking up the blkg > tree rather than fall through to root. > 2. Associate a bio with a blkg in core logic rather than per > controller logic. > 3. Rather than have a css and blkg reference, hold just a blkg ref > as it also holds a css ref. > 4. Switch to percpu ref counting for blkg. > Hmm so reading through this series it's made me realize that iolatency is sort of broken. It relies on knowing if it needs to do something with the bio if there is a blkg associated with it. Before this patchset there wouldn't be a blkg on the bio unless it was specifically associated. I'm going to need to figure out a different way to tag bio's to indicate that blk-iolatency should care about it. Probably add a bio flag or something. Thanks, Josef