Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1249586imu; Thu, 13 Dec 2018 11:49:43 -0800 (PST) X-Google-Smtp-Source: AFSGD/WDql78ob8pZMwhUHmWhTDJtXT/JDSSNrWy1DwmLYYbuQxeoIExoK5Y3OOxn6bVrkZRDpBE X-Received: by 2002:a63:89c2:: with SMTP id v185mr96391pgd.97.1544730583501; Thu, 13 Dec 2018 11:49:43 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1544730583; cv=none; d=google.com; s=arc-20160816; b=rWSeRPj9rIR6UdScQ+Qxx3Osa83Ht/Cn2mui7MEtagyyP1b1rkVHsA4MIGuszXOEpg GV7s6pyQCXJQWeTA5F1dSJRgGjzz22PqZjzq7+HAWys6m61Fr3uzWp8naaSu6xuQFb+y 6hP4JUceU9JNRxKx4t1XrsDtNXPBG6AIioS/Pia8srWo+A9e56pVXQVv1aLCTRHbp4Zm zJZk7f1ihYc3WE4HkW+qLlSqHyANOgty1h7Df2XdHWaQUzMLbqOzDHo75glSMkZE7Oav 0p5+AFYwBr8FLVWn5k+L/pul/phxbiozJc2I08UwRSct2TM9Gs2m5hTq+Sgi8D2PyaIo WHGA== 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=vO0PVlC/h/TD8mOKDcNOZghona65qVLNu9TgC87CmsI=; b=0FhiIRpugigkZqb2hk3mp2aBHnEOZMlZcNlGJRIvCG03nx7neA70CMKNSiyrkDKZDw CVzresTqE9vNz3nKonrLsrbij28Wgsp2ZZyANyHaOKDAS6JTqKPL5SmekG2G0yTADoD8 uqj+jbgTpZaYNkAE5HhWsUsLP0Ilkqo8IznkTYXvHQCsbFxJ1LZqOFYvu+A3t1g8NSRh aJnuDy+7HXGK7FeK+s1GaBVrvH8sZWIMJRWb6+lYK3piB9C4/Qxw5yvB8bFEKD++NsPC cOmRJcVnLxEUfmaCfMrDAjk4skDK3e/w1FMvg/g96mQNAsrcKWgVSFWiwF2+ctgbAEYt Z6Gg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel-dk.20150623.gappssmtp.com header.s=20150623 header.b=0d8wMK6W; 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 f15si2063196plr.144.2018.12.13.11.49.28; Thu, 13 Dec 2018 11:49:43 -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=0d8wMK6W; 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 S1728716AbeLMTsR (ORCPT + 99 others); Thu, 13 Dec 2018 14:48:17 -0500 Received: from mail-it1-f193.google.com ([209.85.166.193]:36822 "EHLO mail-it1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728115AbeLMTsQ (ORCPT ); Thu, 13 Dec 2018 14:48:16 -0500 Received: by mail-it1-f193.google.com with SMTP id c9so5763893itj.1 for ; Thu, 13 Dec 2018 11:48:15 -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=vO0PVlC/h/TD8mOKDcNOZghona65qVLNu9TgC87CmsI=; b=0d8wMK6WrqJrVzfELihclsJcuETB5BnN3+Arx/NlwWZIkj/puRhien7VXSOJzfYbZk 7765Fzp6yB+Pcn2BhLUD4zsM397yly3SvQFucCDiwr30DMMJEtdbWQ7Xq9J5YLhyNKq5 BcW1CX4L7b2SZdQ9OWMjBeOn7x+H0VCgI5uAIl8++xgHeqsSLgwvMqdPblGq1s+I6YLc Y5uqbp6wzckfuuypl4tdT0jU71CFgFMGzfzdHXdehhODUwGOh+0yD1YFRzanLF03kmJP 72XnekOd/HSkK+LrkmfKsgbkzWbpuqOnRoMAH+tgC4slWNZbCYI+0sVUhPrnkfk166F4 LYQA== 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=vO0PVlC/h/TD8mOKDcNOZghona65qVLNu9TgC87CmsI=; b=I+ByIRkXn70/fDMFb+0zppvN1YM7nmWtfskqROe/h/PtoeEIBzzFEaegx1aBAoH33u kIq6JpstXhm9U0xLphx4ce5FrmrLE7g2+j0/lsZ5lz0Qz5rp8aE/vITzjQ7HD4GHma82 0wbB1zJKWKprsF9CY03xC3bTOzmIfJmiQENiP68r5jEMBgKbc1lClhU/YR/9FgfXdvRN 8CfsMtF+5Z9chfCGo2h6t9wkpO/NyU44UPS1iAFYEpanAmL2MbfQdeH9lhAVWi2JKfBZ 9R+ozjPlF+hEQfbjzx7LKIpFJlda1XO/G+FNnuoXLAiwQZXS3OmkhXgD9prrsAGMaR/R P8dQ== X-Gm-Message-State: AA+aEWYOTOm4a8iFCYkUkzxywzmOdf87GBJySfBAF3TeGD/YvBeFpvSY VyrBFuZBFtkIzW8cRpaBtg5/nvOJz35kbw== X-Received: by 2002:a24:4110:: with SMTP id x16mr721767ita.30.1544730493524; Thu, 13 Dec 2018 11:48:13 -0800 (PST) Received: from [192.168.1.56] ([216.160.245.98]) by smtp.gmail.com with ESMTPSA id u5sm1571542itb.33.2018.12.13.11.48.11 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 13 Dec 2018 11:48:12 -0800 (PST) Subject: Re: [PATCH v2] block: fix iolat timestamp and restore accounting semantics To: Dennis Zhou , Tejun Heo , Josef Bacik Cc: 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> From: Jens Axboe Message-ID: <59500829-10f5-fa83-b2db-fcfa4a1cd11d@kernel.dk> Date: Thu, 13 Dec 2018 12:48:11 -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: <20181211230114.65967-1-dennis@kernel.org> 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/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. -- Jens Axboe