I just tested - while running the redis-benchmark command you listed after a BGSAVE smaps lists all anonymous memory as AnonHugePages. So it ends up as THP, although I suppose its possible that it is broken into 4k pages and then adjacent 4k pages are merged back into huge pages. Will see if I can figure out how the lazy PTE copying works.
I do see it now... wasn't testing right before. Goes away as you say when disabling transparent THP. KSM has no effect, contrary to what I thought earlier.
Comments
Can't test it right now, but seems smart, to check if they got split into smaller pages.
I just tested - while running the redis-benchmark command you listed after a BGSAVE smaps lists all anonymous memory as AnonHugePages. So it ends up as THP, although I suppose its possible that it is broken into 4k pages and then adjacent 4k pages are merged back into huge pages. Will see if I can figure out how the lazy PTE copying works.
as a followup, I don't see large latency with huge pages, but I have kernel samepage merging disabled.
I would be interested if this also decreases latency for you:
echo 2 > /sys/kernel/mm/ksm/run
Also check stats here: /sys/kernel/mm/ksm/*
And some documentation here: https://www.kernel.org/doc/Documentation/vm/ksm.txt
Strange... you should definitely see it if you are using jemalloc now that it's clear it's about mass-COW.
I do see it now... wasn't testing right before. Goes away as you say when disabling transparent THP. KSM has no effect, contrary to what I thought earlier.
Thanks a lot for independent confirmation of the issue.