You are not logged in.
Hi, what are the benefits, if any ,of using pds-mq (linux-pf) scheduler instead of muqss (linux-ck) , at the end of last year both released it's last version rebased on kernel 4.20.
Reading on line docs and patches files i cant get which one is more advanced, i tried both, they work fine and both promote kernel responsiviness in desktops. linux-ck being developed by con kolivas I suppose will improve with each release, in the other hand pf includes other features like graysky's GCC patch, UKSM, BFQ improvements. that i am not sure ck includes them or if in a day to day usage makes any difference. CK recently banned BFQ saying is not convinced it performs well and recommend us to use other io scheduler, but he did not say wich one.
Sorry for the long post i hope to make my question clear. pf or ck?
Last edited by miguelmirandag (2019-02-09 22:26:17)
Offline
CK recently banned BFQ saying is not convinced it performs well and recommend us to use other io scheduler, but he did not say wich one.
https://github.com/ckolivas/linux/blob/ … osched#L82 how did CK ban BFQ?
Offline
CK in his blog (http://ck-hack.blogspot.com):
In addition to a resync from 4.18-ck1, there are a number of minor accounting fixes, and I've since dropped BFQ being enabled by default. I've been less than impressed with its latency over the last two kernel releases, and recommend people use another I/O scheduler.
it may be that the word ban is not the most appropriate in this context, the fact is that his patch does not enable bfq by default because he does not like it anymore.
Last edited by miguelmirandag (2019-02-09 23:04:44)
Offline
Does that make any difference to your use case? Are you using `make defconfig` / make `alldefconfig` to pick which IO schedulers are enabled?
http://ck-hack.blogspot.com/2017/08/lin … 0-for.html
4.12-ck2 updates
- BFQ is now in mainline so it is no longer part of the patchset.
- BFQ now enabled by default along with scsi multiqueue to enable booting with it by default.
- Enable setting new kyber I/O scheduler as default as well (I recommend people use BFQ though.)
This is literally correct but as BFQ included in the kernel is an MQ scheduler CK's commit below caused the kernel to try and use an MQ scheduler for an SQ device meaning they were rendered inoperable unless the default of BFQ was overridden.
If the device was MQ then the scheduler could not be altered by the config and CK's commit would not change the kernel.org default of None / mq_deadline.
https://github.com/ckolivas/linux/commi … 54dc945d6c
Edit:
If there is no difference for your use case between pds-mq and linux-muqss does it matter which you use?
Also with 4.20-ck the same as with mainline even with BFQ enabled in the kernel you would still need to manually change default io scheduler from None / mq_deadline.
Last edited by loqs (2019-02-09 23:57:05)
Offline
Regarding BFQ i don't care too much if it is enable by default or not as i always create a udev rule, i was just curious why CK dislike bfq in the last 2 releases. Reading the responses i will stay with ck as is most up to date using graysky repo and I know almost nothing about the other guy just that he made a fork of ck's bfs (the old muqss) and created pds,
Last edited by miguelmirandag (2019-02-10 00:38:59)
Offline
If you want additional information on CK's reasoning or what hardware, config, workload, testing methodology was used as the basis for the dislike of BFQ the best source would seem to be CK.
In your original post you mention graysky's GCC patch as a feature of linux-pf but graysky applies that to the linux-ck packages as well so I thought you were building linux-ck from CK's github account which would not include that.
Last edited by loqs (2019-02-10 00:44:24)
Offline