If the last bvec of the 1st bio and the 1st bvec of the next
bio are physically contigious, and the latter can be merged
to last segment of the 1st bio, we should think they don't
violate sg gap(or virt boundary) limit.
Both Vitaly and Dexuan reported lots of unmergeable small bios
are observed when running mkfs on Hyper-V virtual storage, and
performance becomes quite low. This patch fixes that performance
issue.
The same issue should exist on NVMe, since it sets virt boundary too.
Reported-by: Vitaly Kuznetsov <email address hidden>
Reported-by: Dexuan Cui <email address hidden>
Tested-by: Dexuan Cui <email address hidden>
Cc: Keith Busch <email address hidden>
Signed-off-by: Ming Lei <email address hidden>
Signed-off-by: Jens Axboe <email address hidden>
(cherry picked from linux-next commit 729204ef49ec00b788ce23deb9eb922a5769f55d)
Signed-off-by: Tim Gardner <email address hidden>
after several days of running (way too) many tests, I've got some data
to show that it may be a good idea to drop the DEADLINE I/O scheduler
for Zesty and move to CFQ with buffered writeback throttling (WBT) +
WBT_MQ (WBT multi-queu) enabled.
We originally moved to DEADLINE because of the issues with slow I/O (say
to flash drives) causing applications to hang while blocked on the slow
I/O being flushed out. It seems that with the recent 4.10 WBT driver
and (possibly other block driver changes) we see some performance
benefits also with CFQ, namely:
1. Faster boots. On a 8 thread Xeon CPU E3-1275 I'm seeing a reduction
in usertime boots from 33.92s (Deadline) to ~24.5s (CFQ)
There are some places where CFQ + MQ is less performant than CFQ + MQ +
SQ, and vice-versa. However, my general feeling for Zesty is that we
should give this a try as it seems to work well. The config changes are:
This will give us plenty of time to give this a good test in the next
few months and revert them if we find any problematic corner cases.
(The win on boot time, build times and writes to slow devices) is
probably the most compelling choice for these changes IMHO.
taint/module: Fix problems when out-of-kernel driver defines true or false
Commit 7fd8329ba502 ("taint/module: Clean up global and module taint
flags handling") used the key words true and false as character members
of a new struct. These names cause problems when out-of-kernel modules
such as VirtualBox include their own definitions of true and false.
Fixes: 7fd8329ba502 ("taint/module: Clean up global and module taint flags handling")
Signed-off-by: Larry Finger <email address hidden>
Cc: Petr Mladek <email address hidden>
Cc: Jessica Yu <email address hidden>
Cc: Rusty Russell <email address hidden>
Reported-by: Valdis Kletnieks <email address hidden>
Reviewed-by: Petr Mladek <email address hidden>
Acked-by: Rusty Russell <email address hidden>
Signed-off-by: Jessica Yu <email address hidden>
(cherry picked from commit ea6351698b6c4c51023c49bc7ba4947d399fc3f8 linux-next)
Signed-off-by: Seth Forshee <email address hidden>
Intel has added MODULE_FIRMWARE statements to i915 which refer to
firmware files that they have not yet pushed out to upstream
linux-firmware. This causes the following warnings when
generating the initrd:
W: Possible missing firmware /lib/firmware/i915/kbl_guc_ver9_14.bin for module i915
W: Possible missing firmware /lib/firmware/i915/bxt_guc_ver8_7.bin for module i915
This firmware is clearly optional, and the warnings have been
generating a lot of confusion for users. Remove the offending
MODULE_FIRMWARE statements until Intel makes these files
available.
