What is the cause of a high CPU usage of 'system and compressed memory' in Windows 10?

There is an observation to be made for Windows 10 on my laptop running with 24G memory available, and 2.5G used. There is no 'memory pressure'. Other questions have looked at memory consumption (which isn't the problem here). In all the related questions here and elsewhere, I havn't been able to find an adequate explanation to the issue of this exccessive cpu utilization over the last month or two after one of the Windows 10 updates.

I can accept that there is value in this service or process, but to run continually, and to use additional cpu resources, and as a consequence, use battery power less efficiently, that is the issue I am trying to resolve.

In some article on this site, it was suggested that I turn off SuperFetch, and set a registry entry for PrefetchParameters to 0. I did both and performed a reboot.

I reboot the machine, turn off screen saver, and start the task manager. After a few minutes, the service labeled as 'System and compressed memory' starts taking 5% of my cpu, consistently. My base cpu utilization is maybe 1%, which keeps the fan low. But when the 'system and compressed memory' service runs at the 5%, the fans ramp up. And just keeps running.

Sillyness. Why does that service need to be running consistently like that with no memory pressure? Any additional mechanisms I can try for turning it off or determining what it is actually doing? Are there logs file entries somewhere? Or an in-depth diagnostic tool?

how-to-disable-windows-10-memory-compression -- no real answers here

windows-10-system-process-taking-massive-amounts-of-ram

17993-windows-10-memory-compression

desktop-build-10525-and-windows-10-memory

www.techish.net/system-and-compressed-memory/

windows-10-build-1511-overheating-cpu-fan-always

Windows Performance Recorder - now need a link for info on how to interpret the info

scrub maintenance

Answer

Analyzing the ETL file with WPA shows, that the CPU usage doesn't come from system memory compression. It comes from ntoskrnl.exe!MiScrubMemoryWorker:

Line #, DPC/ISR, Process, Stack Tag, Stack, Count, TimeStamp (s), % Weight

8, , , ,    |    |    |- ntoskrnl.exe!MiScrubMemoryWorker, 79667, , 12,45
9, , , ,    |    |    |    ntoskrnl.exe!MiScrubNode, 79667, , 12,45
10, , , ,   |    |    |    ntoskrnl.exe!MiScrubNodeLargePages, 79667, , 12,45
11, , , ,   |    |    |    ntoskrnl.exe!MiScrubNodeLargePageList, 79667, , 12,45
12, , , ,   |    |    |    |- ntoskrnl.exe!MiScrubPage, 79663, , 12,45
13, , , ,   |    |    |    |    |- ntoskrnl.exe!RtlScrubMemory, 79653, , 12,45
14, , , ,   |    |    |    |    |    |- ntoskrnl.exe!RtlpGenericRandomPatternWorker, 38549, , 6,02

This is a function to test the memory for errors by filling / reading some patterns (ntoskrnl.exe!RtlpGenericRandomPatternWorker).

This is by design and happens when the idle maintenance task kicks up when your device is idle.