Great point about NUMA. It sounds like one request is basically "scan the entire gallery for matches to this image". This is similar to websearch. The ideal thi

Great point about NUMA. It sounds like one request is basically "scan the entire gallery for matches to this image". This is similar to websearch. The ideal thing would be for each of the pinned, per-core threads to allocate and initialize its own memory region and be responsible for scanning just that memory region, so the 96 threads all work on the same request then move on to the next. This would be more efficient as well as have lower latency at <100% utilization. I don't think they're doing that or they wouldn't have talked about increasing concurrency "from 10, 20, 40, 60, 80 and 96". > And the workaround is valid, because THP can currently only map anonymous memory regions such as heap and stack space. Also tmpfs, fwiw. https://www.kernel.org/doc/html/latest/admin-guide/mm/transhuge.html https://www.kernel.org/doc/html/latest/admin-guide/mm/transh... says "Currently THP only works for anonymous memory mappings and tmpfs/shmem. But in the future it can expand to other filesystems." I'm eagerly waiting for that future... I don't think they're using tmpfs because they said "The default tmpfs on the host was untouched and was left at 50% (128 GiB)", and 235 GiB doesn't fit in 128 GiB.