Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1501139

Re: [PATCH V3 00/11] block-throttle: add .high limit

From Tejun Heo <tj@kernel.org>
Newsgroups linux.kernel
Subject Re: [PATCH V3 00/11] block-throttle: add .high limit
Date 2016-10-14 20:40 +0200
Message-ID <ssfyG-4WS-29@gated-at.bofh.it> (permalink)
References (5 earlier) <soEvD-7yl-11@gated-at.bofh.it> <sqaWt-63w-7@gated-at.bofh.it> <sqaWt-63w-5@gated-at.bofh.it> <ssdQd-3JZ-3@gated-at.bofh.it> <ssejg-4bs-17@gated-at.bofh.it>
Organization linux.* mail to news gateway

Show all headers | View raw


Hello, Paolo.

On Fri, Oct 14, 2016 at 07:13:41PM +0200, Paolo Valente wrote:
> That said, your 'thus' seems a little too strong: "bfq does not yet
> handle fast SSDs, thus we need something else".  What about the
> millions of devices (and people) still within 10-20 K IOPS, and
> experiencing awful latencies and lack of bandwidth guarantees?

I'm not objecting to any of that.  My point just is that bfq, at least
as currently implemented, is unfit for certain classes of use cases.

> > FWIW, it looks like the only way we can implement proportional control
> > on highspeed ssds with acceptable overhead
> 
> Maybe not: as I wrote to Viveck in a previous reply, containing
> pointers to documentation, we have already achieved twenty millions
> of decisions per second with a prototype driving existing
> proportional-share packet schedulers (essentially without
> modifications).

And that doesn't require idling and thus doesn't severely impact
utilization?

> > is somehow finding a way to
> > calculate the cost of each IO and throttle IOs according to that while
> > controlling for latency as necessary.  Slice scheduling with idling
> > seems too expensive with highspeed devices with high io depth.
> 
> Yes, that's absolutely true.  I'm already thinking about an idleless
> solution.  As I already wrote, I'm willing to help with scheduling in
> blk-mq.  I hope there will be the opportunity to find some way to go
> at KS.

It'd be great to have a proportional control mechanism whose overhead
is acceptable.  Unfortunately, we don't have one now and nothing seems
right around the corner.  (Mostly) work-conserving throttling would be
fiddlier to use but is something which is useful regardless of such
proportional control mechanism and can be obtained relatively easily.

I don't see why the two approaches would be mutually exclusive.

Thanks.

-- 
tejun

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

Re: Fwd: [PATCH V3 00/11] block-throttle: add .high limit Tejun Heo <tj@kernel.org> - 2016-10-14 18:50 +0200
  Re: [PATCH V3 00/11] block-throttle: add .high limit Paolo Valente <paolo.valente@unimore.it> - 2016-10-14 19:20 +0200
    Re: [PATCH V3 00/11] block-throttle: add .high limit Tejun Heo <tj@kernel.org> - 2016-10-14 20:40 +0200
      Re: [PATCH V3 00/11] block-throttle: add .high limit Paolo Valente <paolo.valente@unimore.it> - 2016-10-16 21:10 +0200
        Re: [PATCH V3 00/11] block-throttle: add .high limit Kyle Sanderson <kyle.leet@gmail.com> - 2016-10-18 07:20 +0200

csiph-web