Preserving the mobility of ZONE

Preserving the mobility of ZONE_MOVABLE

Posted Jan 23, 2021 4:16 UTC (Sat) by zlynx (guest, #2285)
In reply to: Preserving the mobility of ZONE_MOVABLE by corbet
Parent article: Preserving the mobility of ZONE_MOVABLE

It could be possible to trigger another set of moves in the target zone. Movable pages can be located in Normal or DMA zones. Those could be moved into Movable to make room for more pinned pages.

But at some point the admin has to change the system configuration. I use Movable on my desktop so I can get lots of Transparent Huge Pages. I discovered PulseAudio and Steam games would start to act _really weird_ when slab usage got over half of my "kernelcore" setting and slab reclaim went into high gear.

So just like I had to raise kernelcore to 16G to avoid 10+ millisecond long stutters, admins will have to raise it to allow enough pinned pages.

to post comments

Preserving the mobility of ZONE_MOVABLE

Posted Jan 25, 2021 11:14 UTC (Mon) by amarao (guest, #87073) [Link] (1 responses)

Can you elaborate this a bit further, please? What you've done and how you've notice it need to be done?

Preserving the mobility of ZONE_MOVABLE

Posted Jan 25, 2021 17:26 UTC (Mon) by zlynx (guest, #2285) [Link]

Sure.

I built this desktop PC with 64 GiB of RAM. I wanted it to have plenty of THP (Transparent Huge Pages) available so I knew I needed to use ZONE_MOVABLE. I use them for Java and KVM virtual machines. And just for fun.

To create the movable zone, you give one of two command-line options to the kernel. You can use "kernelcore" or "movablecore." They are opposites of each other. I started out using "kernelcore=8G" which provides 8 GiB to the "kernel", but really for all non-movable memory needs.

I have a little script for THP settings I run at bootup as well:

> cd /sys/kernel/mm/transparent_hugepage || exit 1
> echo always > enabled
> echo defer+madvise > defrag
> echo within_size > shmem_enabled
> echo 500 > khugepaged/scan_sleep_millisecs
> echo 500 > khugepaged/alloc_sleep_millisecs

I noticed that playing Youtube videos would start to have strange sound gaps and tracked that to PulseAudio not running on schedule. Which is weird because it is set as real-time. I also noticed that games run from Steam would have sound and video hiccups as well.

I use the "atop" monitoring program a lot and I eventually noticed that when sound problems started to happen, the "slab" number in the memory monitoring would exceed 4G. Which was half of the non-movable RAM allocation.

I am still not exactly sure which kernel operation PulseAudio was hitting 10ms of latency on but when I increased kernelcore to 16G the problem disappeared.

Is this what you wanted to know?