From my last question, another question emerged in my mind. As mentioned there, having low memory causes the operating system to use page-file in Windows, also having low memory causes services like superfetch and... to work more. So my question is that:
Can low memory cause more CPU usage (even slightly more) due to need for memory management in low resource condition? and if the answer is yes, is it Sensible?
Low memory causes the operating system to push memory from least recently used applications out to the page file. This costs some CPU overhead to manage the act of writing data to disk.
Later on when the application read or writes to memory that has been paged out to disk a "page fault" exception is raised. The task is then suspended, the OS figures out where the memory is stored on disk, reads it in to physical RAM, modifies the page table for the application to point at the new physical memory location and then unsuspends the task.
All that work costs some amount of CPU time that would have not been needed if enough physical memory was available. It is likely to be comparatively small compared to other operations, but is still an appreciable amount.
So yes, low memory can cause higher CPU usage.
The problem is that very low memory can cause memory starvation to the point that the system is paging in and out so much data that disk input and output times dominate over everything else.
Quick answer: Yes... um, sort of... but in extreme cases it will have the opposite effect, at least in terms of CPU usage percentage.
In typical cases of "not enough RAM" these days you will not see a much increased hard page fault rate, but you will see a higher overall page fault rate (the additional faults being soft faults). A soft fault involves no disk IO. But code does have to run in the memory manager to resolve the fault.
I'd estimate the time to resolve a soft fault at around a few hundred instruction times. So if every instruction your workload tried to execute raised a soft fault, your work would take about 300 times longer to get done! Assuming the work was all CPU-bound. (Fortunately, the percentage of instructions that raise soft faults is nowhere near that high.)
But this will not increase the measured CPU usage percentage! A thread is either running or it isn't, and from looking at the CPU usage counters, there is no... well, almost* no... visible difference between time spent running your app's code, vs time spent in the memory manager to resolve a soft fault on behalf of your app. The Mm runs in the faulting process's context, so its CPU time just becomes part of your process's time.
*The difference will show up in time spent in kernel vs user mode, since the Mm of course runs in kernel mode.
Of course, if your app has to spend a lot of time in the memory manager, it will be getting a lot less real work done! But the measured CPU usage % won't change.
What will change is the total amount of CPU time (seconds, not %) your thread or your process needs to do the same real work.
The more extreme case is that you're paging to and from disk a lot. i.e. you're incurring hard page faults.
This will actually reduce the measured CPU usage percentage, because time spent waiting for a paging I/O (or any other I/O) to complete is not time spent running code in the CPU. During an I/O the requesting thread is Waiting, or as *nix calls it, "blocked". The time it takes your storage device (disk or even an SSD) to perform an I/O completely swamps the CPU time spent in the memory manager to set up the I/O; so the latter becomes negligible. This applies to a lesser degree even to an M.2 SSD.
So in situations of high hard fault rates you will see your CPU usage, as a percentage, reduced. (i.e. the drive is bottlenecking the CPU.) Just like if your app spent a lot of time reading data files.
But of course, you will see your app taking far longer to complete the work you want it to do. Like the soft fault case, only much worse.
n.b.: The pagefile is not the only file that's used for paging! Every mapped file in the system - which includes every exe and dll that every process is using, plus ntoskrnel itself - is, in essence, a pagefile. So getting rid of the pagefile will not eliminate hard faults nor paging from disk.
I imagine swapping to the disk to use memory would make the CPU have longer I/O cycles causing more general stalling as the CPU/RAM is essentially being fed data at a slower rate. Especially if you have a CPU like Ryzen CPUs that are always craving more bandwidth in terms of their RAM, yeah it can really begin to have a detrimental effect on the CPU. I imagine it does depend on what exactly is getting page filed, but fundamentally, it will make the CPU wait longer on some calls, making it work slower. Hope this answers your question :)
Edit: It also matters where it's page filing, I imagine an M.2 SSD (or any SSD) would help the CPU more than a SATA HDD for example.
Edit 2: Please read Jamie's Comments below this post.
