linux-kernel - Re: [PATCH 0/3] BFQ I/O Scheduler (second take)

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] [day] [month] [year] [list]

Message-ID: <20081112123849.GA14817@gandalf.sssup.it>
Date:	Wed, 12 Nov 2008 13:38:49 +0100
From:	Fabio Checconi <fchecconi@...il.com>
To:	Li Zefan <lizf@...fujitsu.com>
Cc:	jens.axboe@...cle.com, linux-kernel@...r.kernel.org,
	paolo.valente@...more.it,
	Linux Containers <containers@...ts.linux-foundation.org>,
	Vivek Goyal <vgoyal@...hat.com>
Subject: Re: [PATCH 0/3] BFQ I/O Scheduler (second take)

Hi,

> From: Li Zefan <lizf@...fujitsu.com>
> Date: Wed, Nov 12, 2008 10:48:00AM +0800
>
> CC: Linux Containers <containers@...ts.linux-foundation.org>
>     Vivek Goyal <vgoyal@...hat.com>
> 
...
> So this is another cgroup-aware block i/o controller. ;)
> 
> People are sending different proposals for bio controller. A summary
> on this can be found here:
> 	http://marc.info/?l=linux-kernel&m=121798534716673&w=2
> 
> And a new proposal sent by Vivek several days ago:
> 	http://lkml.org/lkml/2008/11/6/227
> 
> And there are some discussions about can we modify the elevator layer
> and create a common layer so we can provide group control for all
> the 4 io schedulers. (in the above mail thread)
> 
> You may share some ideas with us.
> 

  yes, BFQ is another block I/O controller, and the ongoing discussion
is very interesting, as the other patchsets proposed.

BFQ deals with hierarchical scheduling in the same way as the proposed
CFQ extensions do, and it does not handle the I/O traking issue, as we
considered it not belonging directly to the elevator layer.

Talking about what may be interesting from the controller POV, it supports
arbitrary hierarchies (not only two layers) and ioprio classes for cgroups.
It can be easily extended to support any I/O tracking mechanism and
per-device ioprio_class/ioprio (it's just about choosing a sane interface
for that).

The main reasons why we turned BFQ into a cgroup controller were:
  - the algorithm was quite easy to adapt, and in a hierarchical
    context the advantages of using WF2Q+ over RR are more relevant.
  - Being a new scheduler, we had some freedom experimenting with it.
  - Avi asked for it :)

I'd like to stress the fact that the I/O controller thing is _not_ the
main feature of BFQ.  At least at this point of its development, we are
more interested in understanding if the differences it introduces WRT
CFQ (namely, the mixed time-service domain approach, WF2Q+ scheduling,
the feedback on budget lengths, etc.) are of interest or not for the
comminity and/or are worth the effort of a new I/O scheduler.
--
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/