lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 15 Apr 2016 11:08:35 -0400 From: Tejun Heo <tj@...nel.org> To: Paolo Valente <paolo.valente@...aro.org> Cc: Jens Axboe <axboe@...nel.dk>, Fabio Checconi <fchecconi@...il.com>, Arianna Avanzini <avanzini.arianna@...il.com>, linux-block@...r.kernel.org, linux-kernel@...r.kernel.org, Ulf Hansson <ulf.hansson@...aro.org>, Linus Walleij <linus.walleij@...aro.org>, Mark Brown <broonie@...nel.org> Subject: Re: [PATCH RFC 09/22] block, cfq: replace CFQ with the BFQ-v0 I/O scheduler Hello, Paolo. On Fri, Apr 15, 2016 at 04:20:44PM +0200, Paolo Valente wrote: > > It's actually a lot more difficult to answer that with bandwidth > > scheduling. Let's say cgroup A has 50% of disk time. Sure, there are > > inaccuracies, but it should be able to get close to the ballpark - > > let's be lax and say between 30% and 45% of raw sequential bandwidth. > > It isn't ideal but now imagine bandwidth based scheduling. Depending > > on what the others are doing, it may get 5% or even lower of the raw > > sequential bandwidth. It isn't isolating anything. > > Definitely. Nevertheless my point is still about the same: we have to > consider one system at a time. If the workload of the system is highly > variable and completely unpredictable, then it is hard to provide any > bandwidth guarantee with any solution. I don't think that is true with time based scheduling. If you allocate 50% of time, it'll get close to 50% of IO time which translates to bandwidth which is lower than 50% but still in the ballpark. That is very different from "we can't guarantee anything if the other workloads are highly variable". So, I get that for a lot of workload, especially interactive ones, IO patterns are quasi-sequential and bw based scheduling is beneficial and we don't care that much about fairness in general; however, it's problematic that it would make the behavior of proportional control quite surprising. > > As I wrote before, as fairness isn't that important for normal > > scheduling, if empirical data show that bandwidth based scheduling is > > beneficial for most common workloads, that's awesome especially given > > that CFQ has plenty of issues. I don't think cgroup case is workable > > as currently implemented tho. > > I was thinking about some solution to achieve both goals. An option is > probably to let BFQ work in a double mode: sector-based within groups > and time-based among groups. However, I find it a little messy and > confusing. > > Other ideas/solutions? I have no better proposal at the moment :( No idea. I don't think isolation could work without time based scheduling at some level tho. :( Thanks. -- tejun
Powered by blists - more mailing lists