On Thu, 2018-10-04 at 22:39 +-0200, Paolo Valente wrote: +AD4 No, kernel build is, for evident reasons, one of the workloads I cared +AD4 most about. Actually, I tried to focus on all my main +AD4 kernel-development tasks, such as also git checkout, git merge, git +AD4 grep, ... +AD4 +AD4 According to my test results, with BFQ these tasks are at least as +AD4 fast as, or, in most system configurations, much faster than with the +AD4 other schedulers. Of course, at the same time the system also remains +AD4 responsive with BFQ. +AD4 +AD4 You can repeat these tests using one of my first scripts in the S +AD4 suite: kern+AF8-dev+AF8-tasks+AF8-vs+AF8-rw.sh (usually, the older the tests, the more +AD4 hypertrophied the names I gave :) ). +AD4 +AD4 I stopped sharing also my kernel-build results years ago, because I +AD4 went on obtaining the same, identical good results for years, and I'm +AD4 aware that I tend to show and say too much stuff. On my test setup building the kernel is slightly slower when using the BFQ scheduler compared to using scheduler +ACI-none+ACI (kernel 4.18.12, NVMe SSD, single CPU with 6 cores, hyperthreading disabled). I am aware that the proposal at the start of this thread was to make BFQ the default for devices with a single hardware queue and not for devices like NVMe SSDs that support multiple hardware queues. What I think is missing is measurement results for BFQ on a system with multiple CPU sockets and against a fast storage medium. Eliminating the host lock from the SCSI core yielded a significant performance improvement for such storage devices. Since the BFQ scheduler locks and unlocks bfqd-+AD4-lock for every dispatch operation it is very likely that BFQ will slow down I/O for fast storage devices, even if their driver only creates a single hardware queue. Bart.
