02:23:10 <m-relay> <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`)
02:23:19 <m-relay> <j​berman:monero.social> Source: https://github.com/bminor/glibc/blob/40a751b0044114488e841f0223e630596c527c53/malloc/arena.c#L824-L835
02:23:19 <m-relay> <j​berman:monero.social> Source: https://github.com/bminor/glibc/blob/40a751b0044114488e841f0223e630596c527c53/malloc/malloc.c#L1974
02:23:45 <m-relay> <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++)
02:24:13 <m-relay> <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
02:24:19 <m-relay> <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)
02:24:45 <m-relay> <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
02:27:35 <m-relay> <j​berman:monero.social> with this solution in place, it'll be easier to focus attention on bottlenecks
02:31:32 <m-relay> <j​berman:monero.social> *windows 64-bit system default would be `n threads * 2` as well, since windows 64-bit `sizeof(long) == 4`
02:31:40 <m-relay> <j​berman:monero.social> wait that was dumb, this is also linux, ignore lol
02:31:56 <m-relay> <j​berman:monero.social> this is all*