mattdm suggested the upcoming scheduler change should be discussed here. 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,
## 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.
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 :-).
 "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. Upstream discussed this, and the powers that be (mostly Axboe :-) are explicitly expecting us (downstreams) to make this decision.
 BFQ: http://algo.ing.unimo.it/people/paolo/disk_sched/description.php
 "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. 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).
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. 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.
 RHEL7 IO schedulers:
 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.
To complete flickerfree boot support and remove the last modeset
on systems using an Intel iGPU, I've been working with i915 upstream
to make i915.fastboot=1 the default, this is part of:
I've just gotten agreement on a patch for this and a Reviewed-by
for that patch. That patch enables 915.fastboot=1 by default on
Skylake (gen9) and newer Intel graphics.
I would like to cherry-pick this patch and some small related
i915 bugfixes into the Fedora 5.0.0 kernel. This is only intended
for rawhide / F30, I will add a note to rebase-notes that the
patch flipping the default for gen9+ should be dropped for
f29 and older (the bug fixes can stay).
I would like to add these patches to the current rawhide kernel
soon, so that this get as much testing as possible. Is that
ok with you (the Fedora kernel team) ?
gcc9 exposed an underlying issue with some inline asm on s390x. I've emailed
upstream about the issue but it's still not fixed. In the interest of
continuing to test kernels, I've disabled this arch in rawhide kernels
for now. I'll be keeping an eye on this and plan to turn this arch back
on as soon as I can.
Adding explicit bzip2 dependency for perf tool. The bzip2
is used in perf archive script command, and without bzip2
command it fails, like:
$ perf archive
tar (child): bzip2: Cannot exec: No such file or directory
tar (child): Error is not recoverable: exiting now
With explicit bzip2 dependency we're ok:
$ rpm -qp --requires perf-...rpm | grep bzip2
koji build: https://koji.fedoraproject.org/koji/taskinfo?taskID=32223307
Signed-off-by: Jiri Olsa <jolsa(a)kernel.org>
kernel-tools.spec | 1 +
1 file changed, 1 insertion(+)
diff --git a/kernel-tools.spec b/kernel-tools.spec
index a93e789a2caa..6faaa2d17a60 100644
@@ -136,6 +136,7 @@ and the supporting documentation.
%package -n perf
Summary: Performance monitoring for the Linux kernel
%description -n perf
This package contains the perf tool, which enables performance monitoring
I am following the instructions found in
I am trying to get fedora 29 support for microsoft surface pro 3 (including
I am patching the 4.18.18-fc29 kernel, using the patches found in
https://github.com/jakeday/linux-surface, branch 4.18.20-4.
This is what I have done,
git clone https://github.com/jakeday/linux-surface
git checkout 4.18.20-4
fedpkg clone -a kernel
fedpkg switch-branch f29
#going back to 4.18.18,
git reset --hard 87f9453dd6777020e4968779d61437a6f20b3614
for i in ../linux-surface/patches/4.18/*; do ./scripts/newpatch.sh $i; done
cp ../linux-surface/patches/4.18/* .
After running `fedpkg prep` (Is this a good way to test?),
fatal: empty ident name (for <>) not allowed
error: Bad exit status from /var/tmp/rpm-tmp.ul7jtS (%prep)
Removing two of jakeday's patches (0008-wifi.patch, 0009-surface3_power.patch)
solves the issue.
1. This error indicates there is something wrong with the patch files? It is issued by git
Running again `fedpkg prep`,
Found unset config items, please set them to an appropriate value
I added both options to kernel-local file, but the error persists.
It seems the file is not being used.
2. Is it possible to debug the total list of config options, including
those added in kernel-local?
Today 2019-01-15 will be Kernel 4.20 Test Day Test Day! As Fedora 29
will be getting 4.20, we want to test it across all arcs and different
variants of F28 and F29.
So this is an important Test Day! Test Day will focus on testing the new
As always, the event will be in #fedora-test-day on Freenode IRC.