<j​berman:monero.social> By default, glibc will use up to `n threads * 8` arenas on 64-bit systems. Of note, their limit is also platform specific (it's `n threads * 2` on systems where `sizeof(long) == 4`)

<j​berman:monero.social> Source: github.com/bminor/glibc/blob/40a751…596c527c53/malloc/arena.c#L824-L835

<j​berman:monero.social> Source: github.com/bminor/glibc/blob/40a751…630596c527c53/malloc/malloc.c#L1974

<j​berman:monero.social> Personally, I think that's a silly default especially for a program that uses a solid amount of RAM, which monerod already does (and especially so with FCMP++)

<j​berman:monero.social> I still think it's reasonable to limit max arenas to n threads in our case (with a minimum of 2 arenas to match glibc), so we have a sane approach (also recommended by the docs) to limiting contention

<j​berman:monero.social> I don't think we need to over-complicate this and use platform specific limits (both by re-introducing glibc's platform specific NARENAS_FROM_NCORES, and by checking how much total RAM a system has)

<j​berman:monero.social> I think we have a good simple solution here in limiting arenas to n threads (with a min of 2 arenas), and if we notice issues **after** introducing this limit, then I'll deal with that

<j​berman:monero.social> with this solution in place, it'll be easier to focus attention on bottlenecks

<j​berman:monero.social> *windows 64-bit system default would be `n threads * 2` as well, since windows 64-bit `sizeof(long) == 4`

<j​berman:monero.social> wait that was dumb, this is also linux, ignore lol

<j​berman:monero.social> this is all*