On Fri, 8 Sep 2023 09:04:29 +0200 Mattias Rönnblom <hof...@lysator.liu.se> wrote:
> > Also, right now the array is sized at 129 entries to allow for the > > maximum number of lcores. When the maximum is increased to 512 or > > 1024 the problem will get worse. > > Using TLS will penalize every thread in the process, not only EAL > threads and registered non-EAL threads, and worse: not only threads > that are using the API in question. > > Every thread will carry the TLS memory around, increasing the process > memory footprint. > > Thread creation will be slower, since TLS memory is allocated *and > initialized*, lazy user code-level initialization or not. > > On my particular Linux x86_64 system, pthread creation overhead looks > something like: > > 8 us w/o any user code-level use of TLS > 11 us w/ 16 kB of TLS > 314 us w/ 2 MB of TLS. Agree that TLS does cause potentially more pages to get allocated on thread creation, but that argument doesn't make sense here. The rand state is small, and DPDK applications should not be creating threads after startup. Thread creation is an expensive set of system calls.
