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
After the latency spike does the smaps output still list the same amount of AnonHugePages?
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.