Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1272030imu; Thu, 13 Dec 2018 12:11:52 -0800 (PST) X-Google-Smtp-Source: AFSGD/Vomutq+qPmuWL2GovA4hw779zVliQbHemFr/zhib0RSZwEUqtlYY0pJO9Nn4hy3IETlIN4 X-Received: by 2002:a62:c505:: with SMTP id j5mr168751pfg.149.1544731912424; Thu, 13 Dec 2018 12:11:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544731912; cv=none; d=google.com; s=arc-20160816; b=Bydi6O+upFUNique6gidyFVf7cNnYo/NcyoHHxJaMwkIgSvH9XVEL05YbGOeFFPUg8 Y2jPH1dZcE2866r3B5jfs7DDQs0eKXZQ1RuxfoL8a4dmw+qmDQE9ztQECWTLGoozJ9s2 AZkMUKd/w5A1kIdQh9gUhIT7zbdTYxGyj2J84znoFaYOYqifCVih+VDlQCM65ypKG5Ej taH+75s2GGpMM0EPGBu91xaW5oVGgRJhrFjAWKUWKUqIQyFE99AMgAnpfCBbNUhM+gEQ fYO9xVD71kGgRKehWYuDgf4mQ6ESX2HcjWjDmccknA+8bGJTseqgaAXQspnC+3y3eV12 4XoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject:dkim-signature; bh=fHszRcQD/Xo2QERAL0m1tRp8DU2FUA/4azDChFxDoGU=; b=QWqecinwUm7GPC8qaCs6wVABVdfNHYnWbRA2GVu1g9dZkdtFxleDTuoyesXjkm66PH 75nRCNxpdLihtC/e6Jn4PjK7GcNIRG6yT1Z61dKvJBJc5LJaUD7HyPjq646+vPnzu4sm ULFq5w6R4zmJQDw5WXdohq5OMf52CUdhVLcCRsVAg5w3x+N4XwJiMye3oc187Mi4JRvH jDpV6LGHoszUr9akMI+1IRmTS7xezrU4MH1L7cha4aq848RA8DGG7k3cCByxCCuJeMf3 s7dj+Mxu42zsLKQymsxVEm4cnAkb6W5OqXPI+SkkbFdG/CeJzsA9rs2TTRfRPEnplwD9 OBsQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=wJP1SQ8I; 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 v185si2316961pfb.65.2018.12.13.12.11.36; Thu, 13 Dec 2018 12:11:52 -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=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=wJP1SQ8I; 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 S1726435AbeLMUKM (ORCPT + 99 others); Thu, 13 Dec 2018 15:10:12 -0500 Received: from mail-io1-f65.google.com ([209.85.166.65]:33397 "EHLO mail-io1-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726461AbeLMUKL (ORCPT ); Thu, 13 Dec 2018 15:10:11 -0500 Received: by mail-io1-f65.google.com with SMTP id t24so2669776ioi.0 for ; Thu, 13 Dec 2018 12:10:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel-dk.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=fHszRcQD/Xo2QERAL0m1tRp8DU2FUA/4azDChFxDoGU=; b=wJP1SQ8ImzHtwUh0cjnLe7Dk8ufoQYVWa4WBiuA1Q1UDTjqC2eHMHWJIzJ71ZT90N+ O+f4vVZxqMMST9jVOXUCJIsS8bk3k+z9nX1jb/DhOhF1xi318pufij+kPLR5HJMHHVTv lQWGLO9IogK6WHgondokFSd0iaHsFbA9O5EWrFa1nKO1AuOmUDbUqF5QTdlGk85Z+Ljl D6rKlD1DxeTYvoAS67buBkBlKOV70deiksigOln/m3RdCqABptRo5gggXiHpRjkfpCjr CwVRH3ZQnRRJQw+ZTCbX47jyXZWbJZ7cEgHmV0CAuM/84nFJf8weneRjJ1CyEZq+uisQ Lxxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=fHszRcQD/Xo2QERAL0m1tRp8DU2FUA/4azDChFxDoGU=; b=kxYWzofva9cmRvG+iuovixaRigy8x+cdwK470uxH+l8ww1tshs3q28lxfpt/PxHixs 2pOPVFtnF2yTl9wnXkzo5QvNkQQNM7OdYR9m73pDbLJAmvGq5HY/GTt+3JyQZ1wlXPUt rhKma2WxlVxWMMjoO+ItZHHhzYxoqC1mvomcJo0z5Lc1Txu8CKFKaLBHRJIBqy/JIz5e jzS2OTeZbMIJkGFNYvn0FvdmIFgVI18yhBcon3V/LGkQFUqtMp2EKUSitmfa95a/BBB4 tnJqxpLixYWF5ZAqUn+M6q43qSH49hVJ0rWltPNLSieZvjN8LeBS2l2mWftT8osyPO5u NBWQ== X-Gm-Message-State: AA+aEWbK9iZUWNbeJrYJSEnd4G1aNjxbiztZf1Pgcqa/zHgT4XiaIwk9 sj6WDozM8wTrCNzVMw4M/R2MTVWPKXHMsQ== X-Received: by 2002:a5d:9697:: with SMTP id m23mr139037ion.201.1544731809649; Thu, 13 Dec 2018 12:10:09 -0800 (PST) Received: from [192.168.1.56] ([216.160.245.98]) by smtp.gmail.com with ESMTPSA id k2sm1460678itk.35.2018.12.13.12.10.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Dec 2018 12:10:08 -0800 (PST) Subject: Re: [PATCH v2] block: fix iolat timestamp and restore accounting semantics To: Josef Bacik Cc: Dennis Zhou , Tejun Heo , kernel-team@fb.com, linux-block@vger.kernel.org, cgroups@vger.kernel.org, linux-kernel@vger.kernel.org References: <20181211230114.65967-1-dennis@kernel.org> <59500829-10f5-fa83-b2db-fcfa4a1cd11d@kernel.dk> <20181213195208.qgvfeb5ilbf3ttsf@MacBook-Pro-91.local> <20181213200358.e5zxe4tacrwylg32@MacBook-Pro-91.local> From: Jens Axboe Message-ID: <317a289a-5c0a-636b-70af-c3aaaf9b0d81@kernel.dk> Date: Thu, 13 Dec 2018 13:10:07 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: <20181213200358.e5zxe4tacrwylg32@MacBook-Pro-91.local> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 12/13/18 1:03 PM, Josef Bacik wrote: > On Thu, Dec 13, 2018 at 12:59:03PM -0700, Jens Axboe wrote: >> On 12/13/18 12:52 PM, Josef Bacik wrote: >>> On Thu, Dec 13, 2018 at 12:48:11PM -0700, Jens Axboe wrote: >>>> On 12/11/18 4:01 PM, Dennis Zhou wrote: >>>>> The blk-iolatency controller measures the time from >>>>> rq_qos_throttle() to rq_qos_done_bio() and attributes this time to >>>>> the first bio that needs to create the request. This means if a bio >>>>> is plug-mergeable or bio-mergeable, it gets to bypass the >>>>> blk-iolatency controller. >>>>> >>>>> The recent series, to tag all bios w/ blkgs in [1] changed the >>>>> timing incorrectly as well. First, the iolatency controller was >>>>> tagging bios and using that information if it should process it in >>>>> rq_qos_done_bio(). However, now that all bios are tagged, this >>>>> caused the atomic_t for the struct rq_wait inflight count to >>>>> underflow resulting in a stall. Second, now the timing was using the >>>>> duration a bio from generic_make_request() rather than the timing >>>>> mentioned above. >>>>> >>>>> This patch fixes these issues by reusing the BLK_QUEUE_ENTERED flag >>>>> to determine if a bio has entered the request layer and is >>>>> responsible for starting a request. Stacked drivers don't recurse >>>>> through blk_mq_make_request(), so the overhead of using time between >>>>> generic_make_request() and the blk_mq_get_request() should be >>>>> minimal. blk-iolatency now checks if this flag is set to determine >>>>> if it should process the bio in rq_qos_done_bio(). >>>> >>>> I'm having a hard time convincing myself that this is correct... >>>> Maybe we should just add a new flag for this specific use case? Or >>>> feel free to convince me otherwise. >>>> >>> >>> I mean it'll work for now, but then when somebody else wants to do >>> something similar *cough*io.weight*cough* it'll need a new flag. I >>> kind of hate adding a new flag for every controller, but then again >>> it's not like there's thousands of these things. I'm having a hard >>> time coming up with a solution other than a per-tracker flag. As for >>> this specific version, I still think it needs to be in iolatency >>> itself, trying to make it generic just means it'll get fucked up again >>> later down the line. Thanks, >> >> We definitely don't have that many flags, and I'd hate to add a >> per-whatever flag for this. >> >> But do we need that? We really just need single flag for this, my main >> worry was overloading ENTERED. Especially since we're adding different >> clearing and setting for it. If we had a specific one, if it's set, we >> would need to disallow merging for it, I guess. >> >> And there's already BIO_THROTTLED... >> > > Oh well I guess we only really want to know if we saw the BIO, which > should be able to be shared by all the rq_qos implementations. I > think I'd rather just have a BIO_TRACKED to indicate it went through > the normal rq_qos path. Thanks, Agree, so how about renaming BIO_THROTTLED to BIO_TRACKED and using that? -- Jens Axboe