Which I/O scheduler is Fedora switching to in 4.21? mq-deadline or
BFQ?
by Alan Jenkins
Hi
mattdm suggested the upcoming scheduler change should be discussed here.[1] I might not have enough time to talk details at the moment, but I noticed this is coming up relatively soon. This is what I understand so far about the decision.
Thanks for all the software,
Alan
[1] https://unix.stackexchange.com/questions/483881/what-does-fedora-workstat...
## CFQ is scheduled for removal
Jens Axboe is planning to remove the CFQ I/O scheduler in 4.21. That is, CFQ is part of the "legacy" single-queue block layer, which is going to be removed for ease of maintenance.[2]
Axboes last comment on this timing was made *after* the fix for data corruption on MQ. I.e. the data corruption covered by the recent thread on this list.
*Obligatory disclaimer*. Read the paragraph above, and consider waiting for the next stable kernel update, before you test MQ (including BFQ) on your own machine :-).
[2] "It's definitely still going" - Jens Abxoe. https://bugzilla.kernel.org/show_bug.cgi?id=201685#c279
## The kernel wants us to choose our new default
For devices which have only one hardware queue, the new upstream default is mq-deadline. Going from CFQ to mq-deadline is a significant change. For example, the deadline scheduler does not support ionice.
The alternative to the MQ deadline scheduler will be BFQ.[3][4] Upstream discussed this, and the powers that be (mostly Axboe :-) are explicitly expecting us (downstreams) to make this decision.[5]
[3] BFQ: http://algo.ing.unimo.it/people/paolo/disk_sched/description.php
[4] https://unix.stackexchange.com/questions/375600/how-to-enable-and-use-the...
[5] "I'd prefer if the distros would lead the way on this, as theyare the ones that will most likely see the most bug reports" - Jens Axboe, https://www.spinics.net/lists/linux-block/msg31062.html
## Arguments for (or against) BFQ?
Paolo Valente kindly wrote an informative response, which I will copy in to a separate message. The following is my very limited first impression.
Personally I lean towards BFQ by default. It appears nominated as the successor to CFQ, I think it's worthy as such, and it makes distinct improvements of it's own. I would recommend it with more confidence if I understood how the improvements work :-).
The deadline scheduler probably isn't a *complete* disaster. Ubuntu ran with the deadline scheduler for a while.[6] I haven't checked whether they changed the tuning knobs though!
RHEL7 defaults to CFQ for SATA drives. This is notable given that it recommends avoiding (or tuning) CFQ on basically any other server hardware (and specifically to avoid it on hardware RAID).[7]
I've tried BFQ on my laptops hard drive (not SSD). It has some associated tests for responsiveness (the "S" tests). I don't have a real-world feel for it, but I agree the test numbers are an impressive improvement over CFQ.
I don't have results for the S tests on the deadline scheduler. I did note the eponymous "deadline" for sync reads has a default of 500 ms.
The other test I have, is that "deadline" doesn't match CFQ's level of fairness for reads v.s. writes, even with the recent addition of WBT. Neither approached what I would actually call fairness. BFQ did.[8] This is due to BFQ's "compensations" for device writeback caching and NCQ. And allegedly for Linux writeback. These extra compensations are the part I don't understand, so far.[9]
[6] https://askubuntu.com/questions/784442/why-does-ubuntu-16-04-set-all-driv...
[7] RHEL7 IO schedulers:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/...
[8] I tried to closely match the test from the cover letters from the WBT patch series. I don't have detailed statistics, but I believe deadline+WBT was less fair than CFQ. It was definitely not more fair.
https://unix.stackexchange.com/questions/483269/determine-the-specific-be...
[9] https://groups.google.com/forum/#!topic/bfq-iosched/yjZDn_HnLIc
4 years, 3 months
Help remove scriptlets from the kernel?
by Laura Abbott
At DevConf a few weeks ago, Stephen Gallagher and Will Woods gave a talk about
removing rpm scriptlets. The recording hasn't been uploaded yet but the slides
are available https://schd.ws/hosted_files/devconfcz2019/bc/scriptlet-reform-school-3.pdf
The kernel uses a few scriptlets at the moment which will need to be cleaned
up, most likely replaced with file triggers. We'll certainly be looking at this
but if anyone is super excited about cleaning up packaging, this could be
a good project (and much appreciated!)
Thanks,
Laura
4 years, 3 months
toolchain requirements for external kernel modules
by Laura Abbott
I've been experimenting with enabling CONFIG_GCC_PLUGINS in the kernel
since I've heard some people express interest in stackleak (I'm interested
as well). a gcc plugin gets built as an .so file for use during
compilation. This means we need to package this .so file as part
of kernel-devel for building external modules. This is easy to
do but it also now introduces a tighter restriction on the toolchain
used for building modules since gcc will refuse to load a plugin and
fail to build the module if the versions don't match. Arguably, there's
always been a requirement to use the same toolchain version but there may
have been some flexibility for forcing it.
Can anyone see major problems with requiring the same toolchain
version for building external modules as the kernel?
Thanks,
Laura
4 years, 3 months
Re: toolchain requirements for external kernel modules
by Laura Abbott
On 2/15/19 3:47 AM, Florian Weimer wrote:
> * Laura Abbott:
>
>> I've been experimenting with enabling CONFIG_GCC_PLUGINS in the kernel
>> since I've heard some people express interest in stackleak (I'm interested
>> as well). a gcc plugin gets built as an .so file for use during
>> compilation. This means we need to package this .so file as part
>> of kernel-devel for building external modules. This is easy to
>> do but it also now introduces a tighter restriction on the toolchain
>> used for building modules since gcc will refuse to load a plugin and
>> fail to build the module if the versions don't match. Arguably, there's
>> always been a requirement to use the same toolchain version but there may
>> have been some flexibility for forcing it.
>>
>> Can anyone see major problems with requiring the same toolchain
>> version for building external modules as the kernel?
>
> If those kernel modules happen to build userspace components as well
> (and use the right build flags), then they have such a toolchain
> dependency already, indirectly through the annobin plugin.
>
> The main caveat I see is that it is tricky to handle the version
> constraints correctly (both in the plugin and at the RPM level). For a
> long time, the annobin constraints were too tight.
Most modules are probably not going to be compiling userspace
components so I'm not too concerned there.
Thanks for the pointer to annobin though, I hadn't thought about
how to actually specify the requirement in the rpm file. I'm
not sure if this example convinces me I should do gcc plugins
or it's not worth the hassle.
Laura
4 years, 3 months
re-enable CONFIG_JUMP_LABEL on s390x
by Dan Horák
Hi,
the root cause of https://marc.info/?t=154824821000001&r=1&w=2 was
fixed in gcc trunk (only) and it's now available in gcc-9.0.1-0.4.fc30.
Something like the patch bellow is needed, but things get complicated,
because the new constraint won't be available in gcc < 9 (afaik). A
scratch build succeeded - https://koji.fedoraproject.org/koji/taskinfo?taskID=32736584
What I changed
- updated 0001-s390-jump_label-Correct-asm-contraint.patch and added as Patch5xx
- reverted the *config* part of 1b48caa (Disable CONFIG_JUMP_LABEL on s390x)
diff --git a/arch/s390/include/asm/jump_label.h b/arch/s390/include/asm/jump_label.h
index e2d3e6c43395..41dabfd8518d 100644
--- a/arch/s390/include/asm/jump_label.h
+++ b/arch/s390/include/asm/jump_label.h
@@ -22,7 +22,7 @@ static inline bool arch_static_branch(struct static_key *key, bool branch)
".long 0b-.,%l[label]-.\n"
".quad %0-.\n"
".popsection\n"
- : : "X" (&((char *)key)[branch]) : : label);
+ : : "jdd" (&((char *)key)[branch]) : : label);
return false;
label:
return true;
@@ -36,7 +36,7 @@ static inline bool arch_static_branch_jump(struct static_key *key, bool branch)
".long 0b-.,%l[label]-.\n"
".quad %0-.\n"
".popsection\n"
- : : "X" (&((char *)key)[branch]) : : label);
+ : : "jdd" (&((char *)key)[branch]) : : label);
return false;
label:
return true;
With regards,
Dan
4 years, 3 months
