[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <464F6CBE-A63E-46EF-A90D-BF8450430444@unimore.it>
Date: Sat, 31 May 2014 00:23:01 +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 30/mag/2014, alle ore 18:07, Tejun Heo <tj@...nel.org> ha scritto:
> Hello, Paolo.
>
> On Thu, May 29, 2014 at 11:05:31AM +0200, Paolo Valente wrote:
>> this patchset introduces the last version of BFQ, a proportional-share
>> storage-I/O scheduler. BFQ also supports hierarchical scheduling with
>> a cgroups interface. The first version of BFQ was submitted a few
>> years ago [1]. It is denoted as v0 in the patches, to distinguish it
>> from the version I am submitting now, v7r4. In particular, the first
>> two patches introduce BFQ-v0, whereas the remaining patches turn it
>> progressively into BFQ-v7r4. Here are some nice features of this last
>> version.
>
> So, excellent work. I haven't acteually followed the implementation
> of the scheduling logic itself but read all the papers and it seems
> great to me; however, the biggest problem that I have is that while
> being proposed as a separate iosched, this basically is an improvement
> of cfq. It shares most of the infrastructure code, aims the same set
> of devices and usages scenarios and while a lot more clearly
> characterized and in general better performing even the scheduling
> behavior isn't that different from cfq.
>
I am really glad to hear that, thanks.
> We do have multiple ioscheds but sans for anticipatory which pretty
> much has been superceded by cfq, they serve different purposes and I'd
> really hate the idea of carrying two mostly similar ioscheds in tree.
>
> For some reason, blkcg implementation seems completely different but
> outside of that, bfq doesn't really seem to have diverged a lot from
> cfq and the most likely and probably only way for it to be merged
> would be if you just mutate cfq into bfq. The whole effort is mostly
> about characterizing and refining the scheduling algorithm anyway,
> right? I'd really love to see that happening.
>
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.
BTW, we are already working on your recommendations for patch 01.
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