linux-kernel - Re: [PATCH RFC - TAKE TWO - 00/12] New version of the BFQ I/O Scheduler

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 30 May 2014 18:48:54 -0600
From:	Jens Axboe <axboe@...nel.dk>
To:	Tejun Heo <tj@...nel.org>, Paolo Valente <paolo.valente@...more.it>
CC:	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

On 2014-05-30 10:07, Tejun Heo wrote:
> 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.

AS was removed, and exactly for that reason. So lets make one thing very 
clear: we are not going to carry two implementations of CFQ, that differ 
in various ways. That will not happen. We're going to end up with one 
"smart" IO scheduler, not several of them.

> 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.

Patching CFQ would be the right way to go, imho. That would also make it 
very clear what the steps are to get there, leaving us with something 
that can actually be backtracked and debugged. I think the patch series 
already looks pretty good, basically patch #2 "just" needs to be turned 
into a series of patches for CFQ.

What I really like about the implementation is, as Tejun highlights, 
that the algorithm is detailed and characterized. Nobody ever wrote any 
detailed documentation on CFQ - I think the closest is a talk I gave at 
LCA in 2007 or so. That said, the devil is _always_ in the details when 
it comes to nice algorithms. When theory meets practice, then the little 
tweaks and tunings required to not drop 10% there or 20% here is when it 
gets ugly. And that's where CFQ has the history going for it, at least. 
Which is another reason for turning patch #2 into a series of changes 
for CFQ instead. We need to end up with something where we can 
potentially bisect our way down to whatever caused any given regression. 
The worst possible situation is "CFQ works fine for this workload, but 
BFQ does not" or vice versa. Or hangs, or whatever it might be.

-- 
Jens Axboe

--
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/