3 ms·
Sounds like the padding stuff is a false sharing issue. They might want to look into putting 128 bytes of padding between the data structures as well: http://w
by Ono-Sendai 10y ago
Sounds like the padding stuff is a false sharing issue. They might want to look into putting 128 bytes of padding between the data structures as well: http://www.forwardscattering.org/post/29 http://www.forwardscattering.org/post/29
- anarazel 10y agoThat's what the discussed padding patch does (except to only padding to 64bytes on most platforms). There's a downside though - on low concurrency the padding reduces the cache hit ratio sufficiently enough to cause a slowdown. Given we're in code freeze anyway, I've not spent a lot of though on that yet; but I suspect that rearchitecting things so the lines are dirtied fewer times, is the better fix; with less potential for regressions at lower client counts.
- Jweb_Guru 10y agoWould it be possible to dynamically choose the padding at server start time? Given that cache line sizes vary that seems like it might be a prudent choice.
- anarazel 10y ago> Would it be possible to dynamically choose the padding at server start time? I doubt it. Allowing the compiler to generate accesses with lea et al. is quite beneficial; and that'd likely be gone by making this not be a compile time constant. It'd also end up being a tuning knob very very few knew how to tune... > Given that cache line sizes vary that seems like it might be a prudent choice. They usually only vary between architectures. Netburst IIRC was the last time x86 cache line sizes varied. If there's any doubt it's usually ok to just use the higher (128 byte) line size, the "unused" padding cache-line will never be accessed and thus not occupy cache space.
- Ono-Sendai 10y agocache line size is 64 B on recent intel CPUs.
- anarazel 10y agoThat's why I said that we'd use a smaller cache-line size for most architectures. PPC uses 128byte tho..
- Ono-Sendai 10y agook.