Search String: Display: Description: Sort:

Results:

References: [ +subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[RFC\s+PATCHv5\s+3\/6\]\s+ipvs\:\s+use\s+kthreads\s+for\s+stats\s+estimation\s*$/: 9 ]

Total 9 documents matching your query.

1. Re: [RFC PATCHv5 3/6] ipvs: use kthreads for stats estimation (score: 1)
Author: Jiri Wiesner <jwiesner@xxxxxxx>
Date: Wed, 16 Nov 2022 17:41:19 +0100
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
/html/lvs-devel/2022-11/msg00046.html (13,061 bytes)

2. Re: [RFC PATCHv5 3/6] ipvs: use kthreads for stats estimation (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Sat, 29 Oct 2022 17:12:28 +0300 (EEST)
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
/html/lvs-devel/2022-10/msg00040.html (27,736 bytes)

3. Re: [RFC PATCHv5 3/6] ipvs: use kthreads for stats estimation (score: 1)
Author: Jiri Wiesner <jwiesner@xxxxxxx>
Date: Thu, 27 Oct 2022 20:07:51 +0200
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)
/html/lvs-devel/2022-10/msg00027.html (23,890 bytes)

4. Re: [RFC PATCHv5 3/6] ipvs: use kthreads for stats estimation (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Wed, 26 Oct 2022 18:29:39 +0300 (EEST)
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
/html/lvs-devel/2022-10/msg00025.html (11,394 bytes)

5. Re: [RFC PATCHv5 3/6] ipvs: use kthreads for stats estimation (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Mon, 24 Oct 2022 18:01:32 +0300 (EEST)
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
/html/lvs-devel/2022-10/msg00020.html (20,429 bytes)

6. Re: [RFC PATCHv5 3/6] ipvs: use kthreads for stats estimation (score: 1)
Author: Jiri Wiesner <jwiesner@xxxxxxx>
Date: Sat, 22 Oct 2022 20:15:13 +0200
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
/html/lvs-devel/2022-10/msg00019.html (22,146 bytes)

7. Re: [RFC PATCHv5 3/6] ipvs: use kthreads for stats estimation (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Sun, 16 Oct 2022 15:21:10 +0300 (EEST)
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
/html/lvs-devel/2022-10/msg00018.html (16,405 bytes)

8. Re: [RFC PATCHv5 3/6] ipvs: use kthreads for stats estimation (score: 1)
Author: Jiri Wiesner <jwiesner@xxxxxxx>
Date: Sat, 15 Oct 2022 11:21:58 +0200
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
/html/lvs-devel/2022-10/msg00017.html (18,203 bytes)

9. [RFC PATCHv5 3/6] ipvs: use kthreads for stats estimation (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Sun, 9 Oct 2022 18:37:07 +0300
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
/html/lvs-devel/2022-10/msg00013.html (59,266 bytes)


This search system is powered by Namazu