hamadmarri
commented
4 years ago Hi @Alt37
That makes some values questionable (like 300HZ (because with 1000/300 we can't get exact value); 1000HZ or even 500HZ because timer for preemption seem too low). Can we consider 250HZ as the recommended tick rate for Cachy?
The clock ticks will trigger some functions in the scheduler to check and update the current running task and check if it needs to be switched by another enqueued task. The very first version of Cachy was calling the resched_curr per tick, however, the next task could be the same as previous (depends on HRRN value). The recent versions on the other hand reduce the overhead of calling resched_curr every tick, it only calls resched_curr when the next higher HRRN task in runqueue is higher than current running task. Therefore, the current task runs until other task has a higher HRRN. Changing the clock HZ will have very tiny effect. Increasing HZ to lets say 1000hz, will make the scheduler able to detect that there is another task has a higher HRRN than current running task in 1ms precision. This might increase the interactivity feeling in desktops. A 500hz will do the same thing but within 2ms precision, 250hz/4ms and so forth. At the end of the day, it doesn't affect the general HRRN algorithm. Increasing HZ from 250 to 500 or 1000 will preempt current running task (if only there is another task that has higher HRRN) faster for 2ms or 3ms respectively.
I have to remove the HZ mentioning in readme because it is not specific to cachy, it is pretty much similar to CFS. The only difference with CFS is that the current running task will run until another task has lower virtual runtime. Where changing the HZ from 250 to 1000 just makes 1000's preempt check call per second instead of 250 calls.
In my opinion, I think the best value for a desktop is 500HZ. The 500HZ will cause the scheduler ticks every 2ms, which is a reasonable time to give the CPU 2ms to run the task without any interruptions.
100hz is good for battery savings, and mostly throughput. Cachy will 99% runs your mouse/keyboard clicks (due to higher HRRN values since such tasks were sleeping a lot of time) in 10ms - in case of 100hz. If a latency of ~10ms is acceptable, then Cachy might be not bad in latency and performant in 100hz.
1000hz is too high (unless if the difference in 1ms from 500ms has an effect in certain situations). It will reduce throughput since sched ticks calls in CFS/Cachy are expensive compared to Muqss/PDS/BMQ.
Other values such as 250hz and 300hz are OK. I use cachy on 250hz because it matches my distro's default kernel settings for comparison reasons.
about CONFIG_PREEMPT
AFAIK, CONFIG_PREEMPT is to let the kernel thread preemptable. I believe the linux implementation of kernel preemtable is very good and is useful for interactivity since the kernel jobs can pause a bit to let the user space tasks to run. In theory, yes CONFIG_PREEMPT is recommended.
NO_HZ_FULL
If it is good in CFS then most likely it is also good in Cachy since Cachy uses CFS's code for most tasks' balancing jobs.
Thank you for rising these questions. Please let me know if you have any other questions.
Vistaus
raykzhao
Maintainers of tweaked kernels change a lot of settings in config. The most noticeable tweak is CONFIG_HZ (upstream x86 values: 1000, 300, 250, 100; addition upstream ARM values: 500, 200). And Cachy-ies description even mentions
That makes some values questionable (like 300HZ (because with 1000/300 we can't get exact value); 1000HZ or even 500HZ because timer for preemption seem too low). Can we consider 250HZ as the recommended tick rate for Cachy?
Also I'd like to see opinion about CONFIG_PREEMPT and NO_HZ_FULL. The first one is popular among tweaked kernels. NO_HZ is already adopted by some distros but it's not recommended for MuQSS.
Thanks,