Recommended config settings for Cachy

[xalt7x]

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

A task gets preempted in every tick if any task has higher HRRN. If the clock ticks in 250HZ (i.e. CONFIG_HZ_250=y) then a task runs for 4 milliseconds and then got preempted if there are other tasks in the runqueue and if any task has higher HRRN.

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,

[hamadmarri]

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]

Sorry to hijack your topic, but can I ask a small question regarding the config? In the readme there's a section about HRRN and the command sysctl kernel.sched_hrrn_max_lifetime_ms=60000

Do I still need to run that command/add it to sysctl.conf or is that already applied by Cachy?

[hamadmarri]

Sorry to hijack your topic, but can I ask a small question regarding the config? In the readme there's a section about HRRN and the command sysctl kernel.sched_hrrn_max_lifetime_ms=60000

Do I still need to run that command/add it to sysctl.conf or is that already applied by Cachy?

Hi @Vistaus
The default value is 30s. You have the ability to tune this value at run time. On some gaming test my friend did, he said that setting the hrrn_max_lifetime to 6000 (6s) gives more fps stability.

You don't have to run this command, but in some cases changing this value could increase performance.

Thanks

[Vistaus]

Hi @hamadmarri Thanks for the explanation! :)

[raykzhao]

Hi @hamadmarri

I'm wondering whether all the tunable parameters from CFS would still have the similar effect in cachy scheduler. For example, would the CFS tweaks from zen-kernel (zen-kernel/zen-kernel@0786252) still improve the responsiveness of the system?

Regards,
Raymond

[hamadmarri]

Hi @hamadmarri

I'm wondering whether all the tunable parameters from CFS would still have the similar effect in cachy scheduler. For example, would the CFS tweaks from zen-kernel (zen-kernel/zen-kernel@0786252) still improve the responsiveness of the system?

Regards,
Raymond

Hi @raykzhao

Most of the tuned values in zen kernel has an effect to cachy except:

sysctl_sched_wakeup_granularity
normalized_sysctl_sched_wakeup_granularity

Thanks for providing these tuned values, I thought that sysctl_sched_latency has no effect on cachy but apparently it does!

enqueue_task_fair > hrtick_update > hrtick_start_fair > sched_slice > __sched_period > sysctl_sched_latency

And in hrtick_start_fair we have resched_curr which depends on sched_slice. That was not intended to happen in Cachy.
I think we have a bug here :/ .
Edit: actually it doesn't effect.

Thanks