[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160122180844.GM5157@mtj.duckdns.org>
Date: Fri, 22 Jan 2016 13:08:44 -0500
From: Tejun Heo <tj@...nel.org>
To: Shaohua Li <shli@...com>
Cc: linux-kernel@...r.kernel.org, axboe@...nel.dk, vgoyal@...hat.com,
jmoyer@...hat.com, Kernel-team@...com
Subject: Re: [RFC 0/3] block: proportional based blk-throttling
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
Powered by blists - more mailing lists