linux-kernel - Re: [PATCH RFC RESEND 00/14] 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]

Message-ID: <20140530153228.GE16605@redhat.com>
Date:	Fri, 30 May 2014 11:32:28 -0400
From:	Vivek Goyal <vgoyal@...hat.com>
To:	paolo <paolo.valente@...more.it>
Cc:	Jens Axboe <axboe@...nel.dk>, Tejun Heo <tj@...nel.org>,
	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 RESEND 00/14] New version of the BFQ I/O Scheduler

On Tue, May 27, 2014 at 02:42:24PM +0200, paolo wrote:

[..]
> Strong fairness guarantees (already provided by BFQ-v0)
> 
> As for long-term guarantees, BFQ distributes the device throughput
> (and not just the device time) as desired to I/O-bound applications,
> with any workload and regardless of the device parameters.

I don't think most of the people care about strong fairness guarantee.
As an algorithm round robin is not bad for ensuring fairness. CFQ had
started with that but then it stopped focussing on fairness and rather
focussed on trying to address various real issues.

And CFQ's problems don't arise from not having a good fairness algorithm.
So I don't think this should be the reason for taking a new scheduler.

I think instead of numbers, what would help is a short description
that what's the fundamental problem with CFQ which BFQ does not
have and how did you solve that issue.

One issue you seemed to mention is that write is a problem. CFQ 
suppresses buffered writes very actively in an attempt to improve
read latencies. How did you make it even better with BFQ.

Last time I had looked at BFQ, it looked pretty similar to CFQ except
that core round robin algorithm had been replaced by a more fair
algo and more things done like less preemption etc.

But personally I don't think using a more accurate fairness algorithm
is the problem to begin with most of the time.

So I fail to understand that why do we need BFQ.

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