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

Groups > linux.kernel > #1313416 > unrolled thread

[RFC 0/3] block: proportional based blk-throttling

Back to article view | Back to linux.kernel

Contents

  [RFC 0/3] block: proportional based blk-throttling Shaohua Li <shli@fb.com> - 2016-01-20 19:00 +0100
    Re: [RFC 0/3] block: proportional based blk-throttling Vivek Goyal <vgoyal@redhat.com> - 2016-01-20 20:10 +0100
      Re: [RFC 0/3] block: proportional based blk-throttling Shaohua Li <shli@fb.com> - 2016-01-20 20:40 +0100
        Re: [RFC 0/3] block: proportional based blk-throttling Shaohua Li <shli@fb.com> - 2016-01-20 20:50 +0100
          Re: [RFC 0/3] block: proportional based blk-throttling Vivek Goyal <vgoyal@redhat.com> - 2016-01-20 21:00 +0100
          Re: [RFC 0/3] block: proportional based blk-throttling Vivek Goyal <vgoyal@redhat.com> - 2016-01-20 22:20 +0100
            Re: [RFC 0/3] block: proportional based blk-throttling Shaohua Li <shli@fb.com> - 2016-01-20 22:40 +0100
        Re: [RFC 0/3] block: proportional based blk-throttling Vivek Goyal <vgoyal@redhat.com> - 2016-01-20 20:50 +0100
    Re: [RFC 0/3] block: proportional based blk-throttling Tejun Heo <tj@kernel.org> - 2016-01-21 22:20 +0100
      Re: [RFC 0/3] block: proportional based blk-throttling Shaohua Li <shli@fb.com> - 2016-01-21 23:30 +0100
        Re: [RFC 0/3] block: proportional based blk-throttling Tejun Heo <tj@kernel.org> - 2016-01-21 23:50 +0100
          Re: [RFC 0/3] block: proportional based blk-throttling Shaohua Li <shli@fb.com> - 2016-01-22 01:10 +0100
            Re: [RFC 0/3] block: proportional based blk-throttling Tejun Heo <tj@kernel.org> - 2016-01-22 15:50 +0100
              Re: [RFC 0/3] block: proportional based blk-throttling Vivek Goyal <vgoyal@redhat.com> - 2016-01-22 17:00 +0100
                Re: [RFC 0/3] block: proportional based blk-throttling Shaohua Li <shli@fb.com> - 2016-01-22 19:10 +0100
                  Re: [RFC 0/3] block: proportional based blk-throttling Vivek Goyal <vgoyal@redhat.com> - 2016-01-22 20:10 +0100
                    Re: [RFC 0/3] block: proportional based blk-throttling Shaohua Li <shli@fb.com> - 2016-01-22 20:50 +0100
                      Re: [RFC 0/3] block: proportional based blk-throttling Vivek Goyal <vgoyal@redhat.com> - 2016-01-22 21:10 +0100
              Re: [RFC 0/3] block: proportional based blk-throttling Shaohua Li <shli@fb.com> - 2016-01-22 19:00 +0100
                Re: [RFC 0/3] block: proportional based blk-throttling Tejun Heo <tj@kernel.org> - 2016-01-22 19:10 +0100
                  Re: [RFC 0/3] block: proportional based blk-throttling Shaohua Li <shli@fb.com> - 2016-01-22 20:20 +0100
          Re: [RFC 0/3] block: proportional based blk-throttling Vivek Goyal <vgoyal@redhat.com> - 2016-01-22 15:50 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1315228

On Fri, Jan 22, 2016 at 01:08:44PM -0500, Tejun Heo wrote:
> Hello, Shaohua.
> 
> On Fri, Jan 22, 2016 at 09:57:10AM -0800, Shaohua Li wrote:
> > > Let's say per-cgroup buffer budget B is calculated as, say, 100ms
> > > worth of IO cost (or bandwidth or iops) available to the cgroup.  In
> > > practice, this may have to be adjusted down depending on the number of
> > > cgroups performing active IOs.  For a given cgroup, B can be
> > > distributed among the CPUs that are actively issuing IOs in that
> > > cgroup.  It will degenerate to round robin of small budget if there
> > > are too many active for the budget available but for most cases this
> > > will cut down most of cross-CPU traffic.
> > 
> > The cgroup could be a single thread. It uses cpu0's per-cpu budget B-1,
> > move to cpu1 and use another B - 1, and so on
> 
> Sure, just ensure that the total cached is bound by B and expire if
> not used over a certain amount of time.  The thing is as long as we
> can go through percpu cache most of the time, it's all fine.  We can
> spend a lot of processing budget for corner cases.
> 
> > >  cost = F + R * size
> > 
> > F could be IOPS. and the real cost becomes R. How do you get R? We can't
> > simply use R(4k) = 1, R(8k) = 2 .... I tried the idea several years ago:
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lwn.net_Articles_474164_&d=CwIBAg&c=5VD0RTtNlTh3ycd41b3MUw&r=X13hAPkxmvBro1Ug8vcKHw&m=4X56EQmXhfF82BH-eQkQL08afWwbrOErtEVkn5xKsWA&s=_IkvDWMM7AXgh840OrQKndkJpBVcKrGhgLnHkA_aYNg&e= 
> > The idea is the same. But the reality is we can't get R. I don't want to
> > have a random math working for one SSD but not for another.
> 
> Yeah, it'll have to be adaptive.  We can't use fixed values; however,
> note that using bandwidth means that we assume F == 0 and R == 1,
> which wouldn't be appropriate for most devices.

It's true bandwidth means R == 1. But it has a kind of adaptive. The
cgroup bandwidth == share * disk_bandwidth. disk_bandwidth is adaptive.
It might not work well if cgroups have completely different IO pattern
though. 

Thanks,
Shaohua

[toc] | [prev] | [next] | [standalone]

#1315047

On Thu, Jan 21, 2016 at 05:41:57PM -0500, Tejun Heo wrote:

[..]
> A simple approximation of IO cost such as fixed cost
> per IO + cost proportional to IO size would do a far better job than
> just depending on bandwidth or iops and that requires approximating
> two variables over time.  I'm not sure how easy / feasible that
> actually would be tho.

Hi Tejun,

"A fixed cost per IO sounds" like iops and "cost proportional to IO size"
sounds like bandwidth. I am wondering can we dynamically control both
bps and iops rate of cgroup based on cgroup weight and average bw/iops of
device queue. That way a cgroup can not get unfair share of disk neither
by throwing lots of small IOs, nor by sending down a small number of large
IOs.

Will that be good enough.

Thanks
Vivek

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web