Mail Archive Search: <+subject:/^(?:^\s*(re|sv|fwd|fw)[\[\]\d]*[:>-]+\s*)*\[RFC\s+PATCHv4\s+2\/5\]\s+ipvs\:\s+use\s+kthreads\s+for\s+stats\s+estimation\s*$/>

Results:

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

Total 4 documents matching your query.

1. Re: [RFC PATCHv4 2/5] ipvs: use kthreads for stats estimation (score: 1): Author: Jiri Wiesner <jwiesner@xxxxxxx>; Date: Tue, 4 Oct 2022 10:39:09 +0200; I must argue against my own argument: I would not claim exactly that. I would be reluctant to generalize the statement even for modern CPUs manufactured by Intel. Whether or not caching (including fe; /html/lvs-devel/2022-10/msg00002.html (19,062 bytes)
2. Re: [RFC PATCHv4 2/5] ipvs: use kthreads for stats estimation (score: 1): Author: Julian Anastasov <ja@xxxxxx>; Date: Sun, 2 Oct 2022 17:12:41 +0300 (EEST); Hello, Yes, considering possible cgroups integration I prefer namespaces to be isolated. So, 4 * cpumask_weight() would be suitable GENL_UNS_ADMIN_PERM (better netns support) and GFP_KERNEL_ACCOUNT.; /html/lvs-devel/2022-10/msg00001.html (19,057 bytes)
3. Re: [RFC PATCHv4 2/5] ipvs: use kthreads for stats estimation (score: 1): Author: Jiri Wiesner <jwiesner@xxxxxxx>; Date: Sat, 1 Oct 2022 12:52:34 +0200; Apologies for the late response. I got tied up at work. For example, the user space limit on the number of processes does not hold any useful value on my testing machine: 254318 while /proc/sys/kerne; /html/lvs-devel/2022-10/msg00000.html (37,980 bytes)
4. [RFC PATCHv4 2/5] ipvs: use kthreads for stats estimation (score: 1): Author: Julian Anastasov <ja@xxxxxx>; Date: Tue, 20 Sep 2022 16:53:29 +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-09/msg00032.html (61,493 bytes)

Current List: 1 - 4
Page: [1]