[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140530160712.GG24871@htj.dyndns.org>
Date: Fri, 30 May 2014 12:07:12 -0400
From: Tejun Heo <tj@...nel.org>
To: Paolo Valente <paolo.valente@...more.it>
Cc: Jens Axboe <axboe@...nel.dk>, Li Zefan <lizefan@...wei.com>,
Fabio Checconi <fchecconi@...il.com>,
Arianna Avanzini <avanzini.arianna@...il.com>,
Paolo Valente <posta_paolo@...oo.it>,
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
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.
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.
Thanks.
--
tejun
--
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