4 ms·
Is that still true with recent kernels? Around postgres we'd huge problems with earlier kernels with enabled THP, but with recent kernels its gotten to be a pre
by anarazel 8y ago
Is that still true with recent kernels? Around postgres we'd huge problems with earlier kernels with enabled THP, but with recent kernels its gotten to be a pretty small penalty.
- antirez 8y agoStill true and will always because the incompatibility between Redis and huge pages is at a more fundamental level.
- justincormack 8y agoWhat is the incompatibility?
- hashhar 8y agohttps://redis.io/topics/latency#latency-induced-by-transparent-huge-pages https://redis.io/topics/latency#latency-induced-by-transpare...
- anarazel 8y agoIOW, a bad persistence design in redis currently interacts with a suboptimal COW-after-fork implementation in linux.
- antirez 8y agoThere is nothing wrong in the Linux COW implementation. The problem is that 2MB pages are too much to duplicate for a single byte change. The 4kb page works very well to do that instead, and actually is very hard to do better in user-space with a different persistence model. AFAIK only thing that could be improved in Linux is that when THP are enabled, it should split the 2MB page into 4kg pages and copy just that.
- anarazel 8y ago> The problem is that 2MB pages are too much to duplicate for a single byte change. Splitting up such pages into their 4kb counterparts when dirtying a COWed huge page isn't particularly crazy. I don't think there's much reason to do that when huge pages are used, but given THP it seems pretty obvious that there's potential for substantial regressions without that feature. > and actually is very hard to do better in user-space with a different persistence model. Howso? It's not like management of a buffering layer over disks is a particularly new thing. There's plenty of different data stores that have persistence models that don't have the problems (uneven write rate, explosion in memory usage after fork, latency increases due to the increase in page misses, ...) of fork() and then writing out the data in the fork.
- antirez 8y agoHere the problem is different: write on disk a point in time snapshot of what is in memory. Redis is not a common data store.
- the8472 8y agoMaybe they could avoid this issue by cloning in smaller increments via memfd + mmap(..., MAP_PRIVATE)? That's assuming persistence doesn't fundamentally require atomic clone of the whole address space.
- trasz 8y agoWhich is, I believe, exactly what FreeBSD does.