Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1315184
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [RFC 0/3] block: proportional based blk-throttling |
| Date | 2016-01-22 19:10 +0100 |
| Message-ID | <qTOjN-7K8-27@gated-at.bofh.it> (permalink) |
| References | (2 earlier) <qTvTQ-3bF-27@gated-at.bofh.it> <qTwdc-3k7-11@gated-at.bofh.it> <qTxsE-4iV-39@gated-at.bofh.it> <qTLcf-5nI-27@gated-at.bofh.it> <qTOa8-7nC-21@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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://lwn.net/Articles/474164/ > 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. > One possible solution is we benchmark the device at startup and get > corresponding proportion of size. That would only work for IO read. And > how to choose the benchmark is another challenge. Hmmm... yeah, that can be one option although I think it'd still have to be adjusted dynamically. Let's think more about it. Thanks. -- tejun
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
[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
csiph-web