Search String: Display: Description: Sort:

Results:

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

Total 6 documents matching your query.

1. Re: [RFC PATCH 2/4] ipvs: use kthreads for stats estimation (score: 1)
Author: Jiri Wiesner <jwiesner@xxxxxxx>
Date: Thu, 8 Sep 2022 18:00:44 +0200
I meant putting if (!ipvs->enable) return; right before the mutex_lock() statement. -- Jiri Wiesner SUSE Labs
/html/lvs-devel/2022-09/msg00011.html (10,990 bytes)

2. Re: [RFC PATCH 2/4] ipvs: use kthreads for stats estimation (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Wed, 7 Sep 2022 22:01:27 +0300 (EEST)
Hello, I preferred to react to cleanup_net() faster and avoid creating threads if this is what we try to do here. Yes, removing _bh is correct. The risk is the other processes to spin if kthread is i
/html/lvs-devel/2022-09/msg00009.html (18,474 bytes)

3. Re: [RFC PATCH 2/4] ipvs: use kthreads for stats estimation (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Wed, 7 Sep 2022 21:07:18 +0300 (EEST)
Hello, Yes Yes, wait/wakeup would be better alternative, it will avoid the possible priority inversion as Jiri noticed. Probably, the rate of rescheduling can be reduced, so that we can achieve sub-m
/html/lvs-devel/2022-09/msg00007.html (11,252 bytes)

4. Re: [RFC PATCH 2/4] ipvs: use kthreads for stats estimation (score: 1)
Author: Jiri Wiesner <jwiesner@xxxxxxx>
Date: Mon, 5 Sep 2022 15:19:05 +0200
It would save some code to move the ipvs->enable check before the critical section and use a return statement right away. Per-CPU counters are updated from softirq context and read by user space proc
/html/lvs-devel/2022-09/msg00004.html (32,790 bytes)

5. Re: [RFC PATCH 2/4] ipvs: use kthreads for stats estimation (score: 1)
Author: "dust.li" <dust.li@xxxxxxxxxxxxxxxxx>
Date: Mon, 5 Sep 2022 14:47:25 +0800
IIUC, this mutex_lock/unlock() is just used for waiting for the ipvs-e thread schedule back if it had been scheduled out in cond_resched_rcu() ? But not to protect data ? If so, I am wondering if we
/html/lvs-devel/2022-09/msg00001.html (42,258 bytes)

6. [RFC PATCH 2/4] ipvs: use kthreads for stats estimation (score: 1)
Author: Julian Anastasov <ja@xxxxxx>
Date: Sat, 27 Aug 2022 20:41:52 +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-08/msg00019.html (35,501 bytes)


This search system is powered by Namazu