Not a member yet? Why not Sign up today
Create an account  

  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
 
BFQ may not ready for the production environment

#1
These days I noticed that many things about the new I/O Scheduler. 

The first one, BFQ not default in the new version kernel 4.12. We should use a litter trick. I see one way from here. And the best way is using Xanmod kernel. BTW, Thank you, Xan.

The second one. A benchmark test I have been noticed from Phoronix site. BFQ and Kyber I/O scheduler not good enough in those tests. What do you guys think these tesets?

The third one, BFQ not stable for now. I think you guys have been noticed that the re-new version xanmod kernel. For now, I using mq-deadline instead of BFQ and Kyber. I found if edited the /etc/default/grub like this:


Code:
GRUB_CMDLINE_LINUX_DEFAULT="scsi_mod.use_blk_mq=1 elevator=mq-deadline zswap.enabled=1 zswap.compressor=lz4"

After I boot and check io scheduler. The default one is BFQ. So, I edited /etc/rc.local and using .sh file to changed default io scheduler after boot. My .sh file like this:


Code:
#!/bin/bash
echo mq-deadline > /sys/block/sda/queue/scheduler

After boot and check it.


Code:
hl@hl-Inspiron-15-7000-Gaming ~ $ cat  /sys/block/sd*/queue/scheduler
[mq-deadline] kyber bfq none
[mq-deadline] kyber bfq none
hl@hl-Inspiron-15-7000-Gaming ~ $


Any idea changed the defalut io scheduler using better way. Thank you.
Reply

#2
Hello @Houghlangley
glad to meet you again!

I don't like BFQ near since the beginning because imho it's not good for everyone. It was good for me sometimes in the past and sometimes it gave me an amazingly awful behaviour under background enforcement tasks. At least for me, BFQ is not good for the system stability and production tasks and I don't recommend it but for limited tasks only. The current CFQ I/O scheduler is by now the best choice for both HDD and SSD disks whatever the task.

About your last question:
Code:
# to select the XXX I/O scheduler
$ sudo su
@root echo XXX > /sys/block/sda/queue/scheduler
# to see what's enabled
@root cat /sys/block/sda/queue/scheduler
# to set by default in every boot set the echo line at /etc/rc.local file before 'exit  0'
By the way, this easy trick has been post posted dozens of times around the forum. Sleepy
"(...) the grandest occasion the past or present has seen, or the future can hope to see." -- Cervantes.
Reply

#3
(09-07-2017, 12:20 PM)tropic Wrote: Hello @Houghlangley
glad to meet you again!

I don't like BFQ near since the beginning because imho it's not good for everyone. It was good for me sometimes in the past and sometimes it gave me an amazingly awful behaviour under background enforcement tasks. At least for me, BFQ is not good for the system stability and production tasks and I don't recommend it but for limited tasks only. The current CFQ I/O scheduler is by now the best choice for both HDDand SSD disks whatever the task.

About your last question:
Code:
# to select the XXX I/O scheduler
$ sudo su
@root echo XXX > /sys/block/sda/queue/scheduler
# to see what's enabled
@root cat /sys/block/sda/queue/scheduler
# to set by default in every boot set the echo line at /etc/rc.local file before 'exit  0'
By the way, this easy trick has been post posted dozens of times around the forum. Sleepy

Thank you for you replay. I will try my best to test and using Xanmod.
Reply

#4
@HoughLangley
I forgot to answer the question about Phoronix tests: imho benchmarking is very flexible and the results depend on the machine type, the distro installed and additional hardware as well. However, we are talking about complexity and conceptual trends on kernel merging and compiling procedures, so there is no easy facts around the entire process by definition. That means that the benchmarking job should not be reduced to a simple fixed planned structure due to the amount of variables messing around the test. Yes, I'm talking about scalability and mainly about the characteristics of scalability and their impact on performance itself. For example, you can test BFQ & other I/O scheduler with FS-Mark or BlogBench with XanMod (single test), or the same with XanMod and Generic (dual comparison), or the same with different computers, kernels, scenarios or whatever (factorial comparison). Just for these things the tests and benchmarking tasks are extremely weak to conclude persistent facts, because there will always be a better tweak, advance or anything else. Furthermore, there are as many BFQ schedulers as kernels, and we should consider the regressions in performance along the development time as well. Anyway, the easiest way to 'test' something is using it over every scenario you can choose in your system, because it's easier to notice the 'bad' than to notice the 'good'. If you use XanMod one time, Generic kernel will never be the same to your eyes -- if something feels good for you, just use it. Smile
"(...) the grandest occasion the past or present has seen, or the future can hope to see." -- Cervantes.
Reply

#5
(09-07-2017, 02:51 PM)tropic Wrote: @HoughLangley
I forgot to answer the question about Phoronix tests: imho benchmarking is very flexible and the results depend on the machine type, the distro installed and additional hardware as well. However, we are talking about complexity and conceptual trends on kernel merging and compiling procedures, so there is no easy facts around the entire process by definition. That means that the benchmarking job should not be reduced to a simple fixed planned structure due to the amount of variables messing around the test. Yes, I'm talking about scalability and mainly about the characteristics of scalability and their impact on performance itself. For example, you can test BFQ & other I/O scheduler with FS-Mark or BlogBench with XanMod (single test), or the same with XanMod and Generic (dual comparison), or the same with different computers, kernels, scenarios or whatever (factorial comparison). Just for these things the tests and benchmarking tasks are extremely weak to conclude persistent facts, because there will always be a better tweak, advance or anything else. Furthermore, there are as many BFQ schedulers as kernels, and we should consider the regressions in performance along the development time as well. Anyway, the easiest way to 'test' something is using it over every scenario you can choose in your system, because it's easier to notice the 'bad' than to notice the 'good'. If you use XanMod one time, Generic kernel will never be the same to your eyes -- if something feels good for you, just use it. Smile

Best answer. Thank you.
Reply

#6
(09-07-2017, 05:01 PM)HougeLangley Wrote:
(09-07-2017, 02:51 PM)tropic Wrote: @HoughLangley
I forgot to answer the question about Phoronix tests: imho benchmarking is very flexible and the results depend on the machine type, the distro installed and additional hardware as well. However, we are talking about complexity and conceptual trends on kernel merging and compiling procedures, so there is no easy facts around the entire process by definition. That means that the benchmarking job should not be reduced to a simple fixed planned structure due to the amount of variables messing around the test. Yes, I'm talking about scalability and mainly about the characteristics of scalability and their impact on performance itself. For example, you can test BFQ & other I/O scheduler with FS-Mark or BlogBench with XanMod (single test), or the same with XanMod and Generic (dual comparison), or the same with different computers, kernels, scenarios or whatever (factorial comparison). Just for these things the tests and benchmarking tasks are extremely weak to conclude persistent facts, because there will always be a better tweak, advance or anything else. Furthermore, there are as many BFQ schedulers as kernels, and we should consider the regressions in performance along the development time as well. Anyway, the easiest way to 'test' something is using it over every scenario you can choose in your system, because it's easier to notice the 'bad' than to notice the 'good'. If you use XanMod one time, Generic kernel will never be the same to your eyes -- if something feels good for you, just use it. Smile

Best answer. Thank you.

[+1] Wink
Reply

#7
Hello. And Bye.
Reply

#8
2019 Cryptocurrency Investment Guide: http://valeriemace.co.uk/cryptoinvestbitcoin11337
Reply

#9
Senuke Tng Reviews-Can Senuke Tng Make Your Affiliate Marketing: http://valeriemace.co.uk/bestseotools15486
Reply



[-]
Quick Reply
Message
Type your reply to this message here.

Image Verification
Please enter the text contained within the image into the text box below it. This process is used to prevent automated spam bots.
Image Verification
(case insensitive)

Forum Jump:


Users browsing this thread:
1 Guest(s)