Received: by 10.223.164.202 with SMTP id h10csp1056104wrb; Thu, 9 Nov 2017 20:28:17 -0800 (PST) X-Google-Smtp-Source: ABhQp+RPsksVOipsMs7GNtGrXC1tFSZrSdRJo8Rrs1lEGxN+0MYT+6ia8sJklxCDurmT2CSCIh6a X-Received: by 10.99.97.23 with SMTP id v23mr2845976pgb.210.1510288097889; Thu, 09 Nov 2017 20:28:17 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1510288097; cv=none; d=google.com; s=arc-20160816; b=lp9vvUSm9jfUjtHglEkMcd1m+9XvdoQgrkOPaQf2euTc76Fft60NpkGULTvW4SREMg TzPPshEE4Iz8Nzv0L/BoW6KLaIlCzstJH+Tyvwn+6mPkotmPD0A29Vj/KQlmPzdFuofV OwBO2OXJAzpE/E3Pl84Vxe7S3dUKaDVtKkROJV0K0cYm9Key0wn5KWefwXGp5Z3fyymS 3mk1Oslc47VJmmBOsPN4w9bz6Ivs6+yjuCj9vityAbagORLLZTYYZxyH2STQ4WPHo0aO Zh1ZqLJD1QeYZe5NIdSU5bRgeXvLEKP/dvGWVhczRP+PwDXA1C2QwuV+phA2YelVPb5d jHVg== 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=0hbOLDVaWKbwdj5ecQk+9R4tBmvGVL9gHIEvysd+m/s=; b=WnQ3XKmO3XYU15Lrx7x69npPYkpcvk1GcM2wYrm9/xlZiB44nDq1DLgrnuA8ZEooe2 2Djgbd5p9ZLDBB+zaMz6+pU5ZZurGa5KJrDbgoMn9gc7rpJ4K4VDmTut3cmZVQ99ZWiJ 3CTOADE6zmvSofdsDZvkf91vYTpYT7GeFqD7M/t9/e2pJV1Vte5Benp0AZxA4XFtALuD LTugrkhtQNH6KZbiq3ebwxUbid3QsQtdt6Dwjr4FuTTwAgX7rIsrco+SMA4Cvcr+kxDD Jh1PYqyRPB2FvJSJic8XdwLbJSFDarblMTktPBO/KoW+Fnlp1YL4wKmJVlgaIM8VE621 ZMxA== 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 l24si8188933pfi.284.2017.11.09.20.28.06; Thu, 09 Nov 2017 20:28:17 -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 S1755947AbdKJE1R (ORCPT + 83 others); Thu, 9 Nov 2017 23:27:17 -0500 Received: from mail.kernel.org ([198.145.29.99]:56472 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755926AbdKJE1Q (ORCPT ); Thu, 9 Nov 2017 23:27:16 -0500 Received: from kernel.org (unknown [199.201.64.4]) (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 7325A21879; Fri, 10 Nov 2017 04:27:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7325A21879 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 20:27:13 -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: <20171110042713.quytcwbu6g6xwvpt@kernel.org> References: <20171109221924.GB983427@devbig577.frc2.facebook.com> <20171109231212.mbqwyzpmciyshxov@kernel.org> <20171109234258.GD983427@devbig577.frc2.facebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171109234258.GD983427@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 03:42:58PM -0800, Tejun Heo wrote: > Hello, Shaohua. > > On Thu, Nov 09, 2017 at 03:12:12PM -0800, Shaohua Li wrote: > > 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. > > It isn't adaptive for sure. I think it's still useful for the > following reasons. > > 1. The absolute latency target is by nature both workload and device > dependent. For a lot of use cases, coming up with a decent number > should be possible. > > 2. There are many use cases which aren't sensitive to the level where > they care much about the different between small and large > requests. e.g. protecting a managerial job so that it doesn't > completely stall doesn't require tuning things to that level. A > value which is comfortably higher than usually expected latencies > would often be enough (say 100ms). > > 3. It's also useful for verification / testing. I think the absolute latency would only work for HD. For a SSD, a 4k latency probably is 60us and 1M latency is 500us. The disk must be very contended to make 4k latency reach 500us. Not sensitive doesn't mean no protection. If the use case sets rough latency, say 1ms, there will be no protection for 4k IO at all. The baseline latency is pretty reliable for SSD actually. So I'd rather keeping the baseline latency for SSD but using absolute latency for HD, which can be done easily by setting DFL_HD_BASELINE_LATENCY to 0. Thanks, Shaohua From 1583634022955772397@xxx Thu Nov 09 23:44:54 +0000 2017 X-GM-THRID: 1583628779065184979 X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread