On Tue, 19 Mar 2019 11:09:50 -0500 Josef Fortier <fortier@augsburg.edu> wrote:
FWIW...
I run a busy php service. Running perf on it showed it's primary CPU activity was memory compaction. Google suggested that this was THP, and, indeed turning off THP dropped CPU load down noticeably. From what research I could understand, I believe this is essentially the same problem as redis. Lot's of small transactions triggering a lot of excess memory compaction in order to allocate a larger page.
Thanks for the info. Yes, I agree it sounds like a similar situation. I haven't come across perf before, so thanks for that pointer; it looks a bit complicated to run though :( My machine isn't very busy so I doubt I can conduct any useful experiment. Although: $ cat /proc/meminfo ... AnonHugePages: 350208 kB ... so its allocating THP for something. I wonder if setting /sys/kernel/mm/transparent_hugepage/enabled to 'madvise' temporarily would leave your system in the improved state or make it revert to the heavily-loaded state?
On 0319, Per Jessen wrote:
Dave Howorth wrote:
On Tue, 19 Mar 2019 13:49:46 +0100 Per Jessen <per@computer.org> wrote:
The settings are fairly obvious -
always - always use huge pages never - never use huge pages madvise - use huge pages when madvise() requests it.
I am also not certain of when the latter will be useful.
I don't understand why madvise isn't the most useful. Surely it is reasonable that applications that want huge pages simply ask for them?
Just to be on the safe side - madvise() is for apps to tell the kernel about their intended use of memory, i.e. size and access pattern. I guess it means using 2M pages if the app consumes memory in large chunks.
Wrt redis, I guess it uses lots of small chunks of memory, which could suffer from always using chunks that are much bigger than needed.
Indeed, but I still don't understand why it insists on 'never'. Surely 'madvise' fixes its problem?
Erroring on the side of caution ? if they understand madvise() as little as us, saying 'never' is safe.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org