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;
DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org D083E218B0
Date:   Mon, 13 Nov 2017 14:08:04 -0800
From:   Shaohua Li <shli@kernel.org>
To:     Tejun Heo <tj@kernel.org>
Cc:     Jens Axboe <axboe@kernel.dk>, linux-kernel@vger.kernel.org,
        kernel-team@fb.com
Subject: Re: [PATCH 1/2] blk-throtl: make latency= absolute
Message-ID: <20171113220804.xsnc6cfkyjv7bzhq@kernel.org>
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>
 <20171113141849.GH983427@devbig577.frc2.facebook.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20171113141849.GH983427@devbig577.frc2.facebook.com>
User-Agent: NeoMutt/20170609 (1.8.3)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Mon, Nov 13, 2017 at 06:18:49AM -0800, Tejun Heo wrote:
> 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.

I think this is what we don't agree with. The user doesn't really care about
the IO latency. What user care about is 'read' syscall latency or 'fsync'
syscall latency. The syscall could do several 4k IO or 1M IO or mixed. To meet
the syscall latency target, we must control the latency for each IO. If we use
absolute latency, it can only control some IOs. In this case, it's very likely
the syscall latency requirement isn't met. So we do need to know what the
underlying device is.

That said, absolute latency is useful for HD. But on the other hand, HD
baseline is always 4ms for any size IO. So absolute latency = 4ms + slack,
unless you want to specify a smaller than 4ms absolute latency.

Thanks,
Shaohua

From 1583960856828435886@xxx Mon Nov 13 14:19:47 +0000 2017
X-GM-THRID: 1583628779065184979
X-Gmail-Labels: Inbox,Category Forums,HistoricalUnread