Received: by 10.223.164.202 with SMTP id h10csp821999wrb; Thu, 9 Nov 2017 15:13:04 -0800 (PST) X-Google-Smtp-Source: ABhQp+T08sm0jkDeWmv655T/eWfIVAXnYehIzKEMnOhALFA2xWurQBabpTLveOZuZl5viLEb4Km8 X-Received: by 10.84.131.163 with SMTP id d32mr1961435pld.73.1510269184384; Thu, 09 Nov 2017 15:13:04 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510269184; cv=none; d=google.com; s=arc-20160816; b=zPcCF+POLyl4tkQU3BuW52RcNAXhg5ZIE0iAg79UlR6IpHIKOYUkg7tWxUN+Gd1vJt oh3gUtzLJEIVEjeujZcEVx+NME1RzscCOFXLr788f9yy7jCdgjlPFOyop6sPlLvmYWXs aZ6IxAUHR8mTrQUiAnwdgERxxK/zwlonBJDMfpQq10pl7T1e/FNVpcChhj65q16aBSUo JwSCIPbXQM9Lc3G8VDrwt24TnkUhlDpA6N/HRMmsBD9BudylJmt2z90Q7qOu6xl+4DC1 JMBnDJtoWKXfoFmtrpwCtXzJQ2IRbc2rx+joHyBAqkj4e5BFUVYm6HAzeh6QQ8iomI8p +wLg== 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:dmarc-filter:arc-authentication-results; bh=0z7DBfJWDKjYFDn1GDMy1CIhwUfa3EYGeKs4fJZnzyA=; b=FrsORMoaPCLHohc5mHsggKdrGHuuEkQ+xJI1SKOzBVczokIpXGnU0osWF2HNlOtjIL KyVeTzEDCPOP04t9yigJmXGxdgUwbG25jKm73IcexzzCwWnqTz5Q+nuMTQWcUqlUX9cA 6uHGbkSmesfo+51FYDznMvxqfvI3jh8R4tRP4WNcSrLo+//waTg1snPxOx9rEeOhleYZ 7o3x4e5XaZDp4FXvxKT64+tkF0vLk/jANQOxaeL/13pF9FGk+QWXks2DqCsbswXFDPGE gpLJ9+GCSP+bPiVb6XPcAJsX7JRuu3i4SA2wLXP639si+4UxrryK+5/EgltggtBMDUx3 VIfw== ARC-Authentication-Results: i=1; mx.google.com; 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 r15si7447568pgt.18.2017.11.09.15.12.51; Thu, 09 Nov 2017 15:13:04 -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; 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 S1754802AbdKIXMP (ORCPT + 83 others); Thu, 9 Nov 2017 18:12:15 -0500 Received: from mail.kernel.org ([198.145.29.99]:58032 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753850AbdKIXMO (ORCPT ); Thu, 9 Nov 2017 18:12:14 -0500 Received: from kernel.org (unknown [199.201.64.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id BF48C21911; Thu, 9 Nov 2017 23:12:13 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org BF48C21911 Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=kernel.org Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=shli@kernel.org Date: Thu, 9 Nov 2017 15:12:12 -0800 From: Shaohua Li To: Tejun Heo Cc: Jens Axboe , linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH 1/2] blk-throtl: make latency= absolute Message-ID: <20171109231212.mbqwyzpmciyshxov@kernel.org> References: <20171109221924.GB983427@devbig577.frc2.facebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171109221924.GB983427@devbig577.frc2.facebook.com> User-Agent: NeoMutt/20170609 (1.8.3) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Nov 09, 2017 at 02:19:24PM -0800, Tejun Heo wrote: > Currently, the latency= parameter specifies the extra latency on top > of the estimated baseline latency. This doesn't seem ideal for the > following two reasons. > > 1. Sometimes we want to use absolute target latencies, especially as > the baseline latency estimation isn't always reliable. > > 2. If we want to set a latency target relative to the estimated > baseline latency, it makes a lot more sense to express the target > as a percentage of the baseline (say, 120% of the expected latency) > rather than the baseline latency + an absolute offset. > > This patch makes the existing latency= parameter to be interpreted as > an absolute latency target instead of an offset to the baseline. The > next patch will add support for relative latency target expressed in > terms of percentage. > > While this is a userland visible change, io.low support is still > evoling and highly experimental. This isn't expected to break any > actual usages. The percentage latency makes sense, but the absolute latency doesn't to me. A 4k IO latency could be much smaller than 1M IO latency. If we don't add baseline latency, we can't specify a latency target which works for both 4k and 1M IO. Thanks, Shaohua > Signed-off-by: Tejun Heo > Cc: Shaohua Li > --- > block/blk-throttle.c | 3 +-- > 1 file changed, 1 insertion(+), 2 deletions(-) > > --- a/block/blk-throttle.c > +++ b/block/blk-throttle.c > @@ -2299,8 +2299,7 @@ void blk_throtl_bio_endio(struct bio *bi > > bucket = request_bucket_index( > blk_stat_size(&bio->bi_issue_stat)); > - threshold = tg->td->avg_buckets[bucket].latency + > - tg->latency_target; > + threshold = tg->latency_target; > if (lat > threshold) > tg->bad_bio_cnt++; > /* From 1583628779065184979@xxx Thu Nov 09 22:21:33 +0000 2017 X-GM-THRID: 1583628779065184979 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread