On 24 Apr 2020, at 18:51, William Tu wrote:
On Fri, Apr 24, 2020 at 3:06 AM Eelco Chaudron <[email protected]>
wrote:
<SNIP>
her ideas on the above or on how to optimize the stack usage?
Hi Eelco,
Can we just increase the stack space to a larger value?
Ex: setting ulimit -s to 32Mb
William
You are right, I should have mentioned the problem statement why this
might not be desired.
Let's assume you have a system with 56 cores. In this case, you will
get
roughly 56 threads, all taking 32M, so 1.7G. To make it even worse we
run OVS with the mlockall() option so all memory gets reserved and
pined
into memory...
I see, thanks!
I know the number of cores can be tuned with
n-revalidator-threads/n-handler-threads and the stack size with
systemd
(in our case). But it would be good the minimize the stack usage in
general, so we can avoid all this setup specific tuning.
Agree, we should definitely think about how to minimize the stack.
For short term solution, can we setrlimit() to 32M RLIMIT_STACK for
handler-threads and mlock() only heap memory?
Guess for the short term solution we will just increase the stack size
in the needed cases.
Your suggestion does not help much, as what I’ve learned over the
years is that customers prefer a deterministic forwarding path, even
over performance. Not having the mlockall() is making this deterministic
behavior worse, even more in the DPDK case.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev
