[ovs-dev] 4K resubmit limit and stack size usage

[Eelco Chaudron]

On 24 Apr 2020, at 18:51, William Tu wrote:

> On Fri, Apr 24, 2020 at 3:06 AM Eelco Chaudron <echaudro at redhat.com> 
> 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.