[ANNOUNCE] bfq-v3r3 for 3.3 is ready

34 views
Skip to first unread message

Paolo Valente

unread,
Apr 5, 2012, 10:44:41 AM4/5/12
to bfq-i...@googlegroups.com, sabayo...@gnome.org, zen_k...@googlegroups.com
Hi,
at last this new version is ready, thanks to the hard work of Arianna
Avanzini, who prepared the initial port to 3.3, took the opportunity to
improve latency a bit more and fixed the bug reported below. This is the
changelog for this new version:

- Bugfix: removed an important error causing occasional kernel panics when
moving a process to a new cgroup. The panic occurred if:
1) the queue associated to the process was idle when the process was
moved
and
2) a new disk request was inserted into the queue just after the move.

- Further latency improvement through a better treatment of low-bandwidth
async queues.

Unfortunately, the above bug is present in all previous versions of BFQ.
The functionality affected by this bug seems however to be rarely used,
as we have not yet received any report of this panic. We will be glad to
fix the bug in each version for which someone will ask as to do.

Paolo


Bryce Lynch

unread,
Apr 5, 2012, 11:23:05 AM4/5/12
to bfq-iosched
Many thanks for your continued work on bfq!

Kyle Sanderson

unread,
Apr 5, 2012, 3:43:45 PM4/5/12
to bfq-i...@googlegroups.com
Very cool. Thanks!

Micron

unread,
Apr 5, 2012, 3:44:55 PM4/5/12
to bfq-iosched
Thanks!

Marco Piazza

unread,
Apr 5, 2012, 6:31:56 PM4/5/12
to bfq-iosched
Many thanks.

Tried here, with a brand new shining 3.3.1 with zcache+frontswap: work
very well. Interactivity is great!

I'm using with bfqio connected to libpam-systemd, with which user
session are under cpu and bfqio controllers and interactivity is good.
The only use case in which interactivity "suffers" is when doing a
dpkg install: probably "dpkg fsyncing" can not be well balanced in a
disk scheduler.
Did you try this case? Is a known case in which bfq doesn't work well?
I must admit that also cfq suffers in such case and IMHO cfq suffers a
lot more.

The only bugs I found are:
1) a kernell oops, using bfqio controller in systemd for system
services (not pam.d session tracking).
If you want a trace I can send you a photo of the kernel panic.
2) a kernel oops (using bfq as default scheduler with bfqio) and
passing as a kernel option elevator=cfq in grub menu. Kernel panics
somewhere in a path related to bfq.

Anyway, great work.
Marco

Paolo Valente

unread,
Apr 6, 2012, 1:47:16 AM4/6/12
to bfq-i...@googlegroups.com
Il 06/04/2012 00:31, Marco Piazza ha scritto:
> Many thanks.
>
> Tried here, with a brand new shining 3.3.1 with zcache+frontswap: work
> very well. Interactivity is great!
Glad to hear it.

>
> I'm using with bfqio connected to libpam-systemd, with which user
> session are under cpu and bfqio controllers and interactivity is good.
> The only use case in which interactivity "suffers" is when doing a
> dpkg install: probably "dpkg fsyncing" can not be well balanced in a
> disk scheduler.
> Did you try this case? Is a known case in which bfq doesn't work well?
> I must admit that also cfq suffers in such case and IMHO cfq suffers a
> lot more.
This is a very interesting case. Probably the higher latency is caused
by the many writes originated by dpkg. However I have also learned that
unexpected truths can often be found through the traces in these cases :)

>
> The only bugs I found are:
> 1) a kernell oops, using bfqio controller in systemd for system
> services (not pam.d session tracking).
> If you want a trace I can send you a photo of the kernel panic.
> 2) a kernel oops (using bfq as default scheduler with bfqio) and
> passing as a kernel option elevator=cfq in grub menu. Kernel panics
> somewhere in a path related to bfq.
Thanks for the bug report and for your willingness to help. I think
Arianna will get in touch with you soon.

Paolo
> Anyway, great work.
> Marco
>
>

Arianna Avanzini

unread,
Apr 6, 2012, 2:22:12 AM4/6/12
to bfq-i...@googlegroups.com
Il giorno venerdì 6 aprile 2012 00:31:56 UTC+2, Marco Piazza ha scritto:
Many thanks.

Tried here, with a brand new shining 3.3.1 with zcache+frontswap: work
very well. Interactivity is great!

I'm using with bfqio connected to libpam-systemd, with which user
session are under cpu and bfqio controllers and interactivity is good.
The only use case in which interactivity "suffers" is when doing a
dpkg install: probably "dpkg fsyncing" can not be well balanced in a
disk scheduler.
Did you try this case? Is a known case in which bfq doesn't work well?
I must admit that also cfq suffers in such case and IMHO cfq suffers a
lot more.

The only bugs I found are:

Hello,

thank you for reporting the problems you found.
 
1) a kernell oops, using bfqio controller in systemd for system
services (not pam.d session tracking).
If you want a trace I can send you a photo of the kernel panic.
2) a kernel oops (using bfq as default scheduler with bfqio) and
passing as a kernel option elevator=cfq in grub menu. Kernel panics
somewhere in a path related to bfq.

Traces for both cases would be most welcome, thank you for offering to help. May I also ask which Linux distribution do you use?
 

Anyway, great work.
Marco

Reply all
Reply to author
Forward
0 new messages