linux-kernel - Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra 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>] [day] [month] [year] [list]

Message-ID: <16e5a714-69c3-e04b-4d10-9f47e01f704e@netscape.net>
Date:   Sun, 30 Oct 2016 18:48:56 +0100
From:   Manuel Krause <manuelkrause@...scape.net>
To:     linux-kernel@...r.kernel.org
Subject: Re: [PATCH 00/14] introduce the BFQ-v0 I/O scheduler as an extra
 scheduler

Dear blk-mq maintainers,

Since years now I use the BFQ disk IO scheduler by default, 
always fetching the newest release.

Now a reality story of mine:
For a clean BUG hunt, I was forced to leave out BFQ for a week 
recently. Result was an unusable experience with CFQ. Long time 
pauses of desktop applications' startup, even KDE menus NOT 
opening, when CFQ did "fair" queuing, of course at its best. ;-)

Next, in my usage pattern, often making use of /dev/shm, what is 
backed by swap on 2nd disk, is highly eased by BFQ, as there is 
no blocking for the rest of the system. CFQ likes to stay 
uninteractive until done: No mouse pointer etc.

When CFQ people do like that... they haven't understood linux' 
present/ future goals, and maybe have no usage experience to have 
the right to discuss this at all.

And until blq-mq+ is matured, mmmh, o.k., 
feature-ready-and-proof, mmmh, o.k. ready with brainstorming... 
in ? years...

there's a still actual (!) wish of Linux users (!) for years now 
(!), to include BFQ as an addon I/O scheduler into mainline kernel.

Sidenote against false-talkers: Paolo Valente and his team have 
always shown to offer updated patches for newly appeared kernel 
releases.

Best regards,
Manuel Krause