OK, I agree that volutary preemption without CONFIG_PREEMPT_RCU will need a preemption point in ip_vs_tick_estimation(). I do not see that as an improvement as well. -- Jiri Wiesner SUSE Labs
Hello, OK, then we can try some sequence of 3 x (pause+4) tests, for example, pause, t1, t2, t3, t4, pause, t5... t12. More tests and especially the delay in time will ensure the CPU speed is increas
Yes, my testing confirms that it is the CPU frequency governor. On my Intel testing machine, the intel_pstate driver can use the powersave governor (which is similar to the ondemand cpufreq governor)
Hello, Hm, I tried some ideas but result is not good at all. chain_max looks like a good implicit way to apply cond_resched rate and to return to some safe position on return. Other methods with arra
Hello, Hm, can it be some cpufreq/ondemand issue causing this? Test can be affected by CPU speed. Hm, yes. Due to the RUNNING state, msleep works for testing. Then I'll add such pause between the tes
I agree that even if the max chain length was underestimated in many cases it can be expected that there will be occasions on which the max chain length would be just right. If parameters of the algo
Hello, Yes, our goal allows underestimation of the tick time, 2-3 times is expected and not a big deal. It is not a problem to add some wait_event_idle_timeout calls to sleep before/between tests if
I have tested this. There is one problem: When the calc phase is carried out for the first time after booting the kernel the diff is several times higher than what is should be - it was 7325 ns on my
Estimating all entries in single list in timer context causes large latency with multiple rules. Spread the estimator structures in multiple chains and use kthread(s) for the estimation. Every chain