| 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: Sat, 31 May 2014 01:54:34 +0200 From: Paolo Valente <paolo.valente@...more.it> To: Tejun Heo <tj@...nel.org> Cc: Jens Axboe <axboe@...nel.dk>, Li Zefan <lizefan@...wei.com>, Fabio Checconi <fchecconi@...il.com>, Arianna Avanzini <avanzini.arianna@...il.com>, linux-kernel@...r.kernel.org, containers@...ts.linux-foundation.org, cgroups@...r.kernel.org Subject: Re: [PATCH RFC - TAKE TWO - 00/12] New version of the BFQ I/O Scheduler Il giorno 31/mag/2014, alle ore 01:28, Tejun Heo <tj@...nel.org> ha scritto: > Hello, > > On Sat, May 31, 2014 at 12:23:01AM +0200, Paolo Valente wrote: >> I do agree that bfq has essentially the same purpose as cfq. I am >> not sure that it is what you are proposing, but, in my opinion, >> since both the engine and all the new heuristics of bfq differ from >> those of cfq, a replacement would be most certainly a much easier >> solution than any other transformation of cfq into bfq (needless to >> say, leaving the same name for the scheduler would not be a problem >> for me). Of course, before that we are willing to improve what has >> to be improved in bfq. > > Well, it's all about how to actually route the changes and in general > whenever avoidable we try to avoid whole-sale code replacement > especially when most of the structural code is similar like in this > case. Gradually evolving cfq to bfq is likely to take more work but > I'm very positive that it'd definitely be a lot easier to merge the > changes that way and people involved, including the developers and > reviewers, would acquire a lot clearer picture of what's going on in > the process. I understand, and apologize for proposing an inappropriate shortcut. > For example, AFAICS, most of the heuristics added by the > later patches are refined versions of what's already in cfq and at > least some are applicable regardless of the underlying scheduling > algorithm. Absolutely correct. > It all depends on the details but, for example, steps like > the following would be it a lot easier to get merged. > > * Identify the improvements which can be applied to cfq as-is or with > some adaptation and apply those improvements to cfq. > > * Make prepatory changes to make transition to new base scheduling > algorithm easier. > > * Strip out or disable cfq features which get in the way of > conversion. > > * Switch the base algorithm to the timestamp based one. > > * Rebuild stripped down features and apply new heuristics, > optimizations and follow-up changes. > OK, we can try. > I understand that this might be non-significant amount of work This may be a non-negligible difficulty, as Arianna, who is actively helping me with this project, and I are working on bfq in our (little) spare time. But if you are patient enough, we will be happy to try to make it one step at a time. > but at > the same time it's not something which is inherently difficult. It's > mostly logistical after all and I'd be happy to help where I can. > This is certainly reassuring for us. Thanks again, Paolo > Thanks. > > -- > tejun -- Paolo Valente Algogroup Dipartimento di Fisica, Informatica e Matematica Via Campi, 213/B 41125 Modena - Italy homepage: http://algogroup.unimore.it/people/paolo/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists