From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752767AbdKMOSz (ORCPT ); Mon, 13 Nov 2017 09:18:55 -0500 Received: from mail-qt0-f169.google.com ([209.85.216.169]:49669 "EHLO mail-qt0-f169.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751104AbdKMOSw (ORCPT ); Mon, 13 Nov 2017 09:18:52 -0500 X-Google-Smtp-Source: AGs4zMYzJFhOypxqeMoKDuxheqmXfBDJmIftSiGtta940/30QUwqdT8jSMoFxLRHV28NsjTwVsyWqg== Date: Mon, 13 Nov 2017 06:18:49 -0800 From: Tejun Heo To: Shaohua Li Cc: Jens Axboe , linux-kernel@vger.kernel.org, kernel-team@fb.com Subject: Re: [PATCH 1/2] blk-throtl: make latency= absolute Message-ID: <20171113141849.GH983427@devbig577.frc2.facebook.com> References: <20171109221924.GB983427@devbig577.frc2.facebook.com> <20171109231212.mbqwyzpmciyshxov@kernel.org> <20171109234258.GD983427@devbig577.frc2.facebook.com> <20171110042713.quytcwbu6g6xwvpt@kernel.org> <20171110154314.GE983427@devbig577.frc2.facebook.com> <20171113042940.d6lcarmnakuctinn@kernel.org> <20171113112710.GG983427@devbig577.frc2.facebook.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171113112710.GG983427@devbig577.frc2.facebook.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, Shaohua. Just a bit of addition. On Mon, Nov 13, 2017 at 03:27:10AM -0800, Tejun Heo wrote: > What I'm trying to say is that the latency is defined as "from bio > issue to completion", not "in-flight time on device". Whether the > on-device latency is 50us or 500us, the host side queueing latency can > be in orders of magnitude higher. > > For things like starvation protection for managerial workloads which > work fine on rotating disks, the only thing we need to protect against > is excessive host side queue overflowing leading to starvation of such > workloads. IOW, we're talking about latency target in tens or lower > hundreds of millisecs. Whether the on-device time is 50 or 500us > doesn't matter that much. So, the absolute latency target can express the requirements of the workload in question - it's saying "if the IO latency stays within this boundary, regardless of the underlying device, this workload is gonna be happy enough". There are workloads which are this way - e.g. it has some IOs to do and some deadline requirements (like heartbeat period). For those workloads, it doesn't matter what the underlying device is. It can be a rotating disk, or a slow or lightening-fast SSD. As long as the absolute target latency is met, the workload will be happy. The % notation can express how much proportional hit the workload is willing to take to share the underlying device with others - "I'm willing to take 20% extra hit in latency so that I can be a nice neighbor", which also makes sense to me. The baseline + slack (the current one) is the mix of the two. IOW, the configuration is dependent on both the workload requirements and the performance characteristics of the underlying device - you can't use a single value across different workloads or devices. We can absolutely keep supporting this but I think it fits worse than the previous two and am having a bit of hard time to come up with why we'd want this. Thanks. -- tejun