Why So Many Hard Pagefaults in Latency Mon

[Mark Morgon-Shaw]

I've been tweaking my system as I've just replaced an Nvidia GT710 which was the driver with the DPC highest latency on my system with an RX550 instead. 

I'm getting better results now but I noticed I still have a high number of hard pagefaults. I left CBB playing a project on a loop for a couple of hours whilst LatencyMon was running 

My system is:

Ryzen 3900x - 32gb DDR 3600 - 500gb NVME Boot Drive ( CBB install on it too )  - 1TB SDD for projects etc - Audient ID4 interface - Win 10 2004 ( updated to latest everything today as part of install )  -  CBB version 2020-09 Build 006 64bit ( set to agressive thread scheduling 3 ).

All drivers up to date - Also running Bitfenderand and Sonarworks Systemwide

All onboard audio disabled in BIOS and Device Manager.

Does anyone know why so may Hard Pagefaults would occur, it's not like I'm low on ram  - there was still around 18gb free whilst this test was running

I'm wondering if my AV software is causing an issue ? 

 

  

 

 

[JonD]

I'd disable AV and run latencymon again...

[Glenn Stanton]

as a note - i exclude the cakewalk executable as a running processing and also the WAV files in my project directories. this seems to eliminate the AV constantly trying to "test" the files and still provide most of the AV functionality for all other processes and files...

[Robert Bone]

Noel Borthwick has indicated, on at least a couple of occasions, that the ThreadSchedulingModel value of 3 is something he is still working on, and not to use it, at this time.

I would suggest you alter that to use the middle option for that parameter '2', regardless of anything else you try.

 

[Mark Morgon-Shaw]

I've set up the exclusions in Bitfender - the default Cakewalk folder on my C : drive  as well as my Project folder and Samples folder which are each on their own drives.

There seems to be a drastic reduction in CBB hard pagefaults - Successs !

I also switched back to Threadscheduling 2 although it's seemed to be working well for me since one of the more recent updates.

I've not ran the test for as long as before but it would seem LatencyMon is much happier now too.

I ran a typical project with about 15-16 VSTi's ( mainly Kontakt Libraries )  and all my mix plugins running at 128 samples and although there is one spot where it drops a buffer or two it plays well. 

 

[bitflipper]

Every instruction your CPU executes, every piece of data it handles, they all come from either cache or main memory. In other words, from RAM. That means that before any code can be run, before any sample can be loaded, the data has to first be moved from disk into memory.

Once a given chunk of data has been read, the next time a program needs it it'll be found in RAM. But the first time, the data isn't there so the program has to stop what it's doing and wait for the data to be transferred from disk. That's a hard page fault. After the page fault has been handled, the program can now re-request the data or code block and it will be there waiting.

That means when you first start up Cakewalk, you'll get page faults because the program hasn't been run before. When Cakewalk loads Kontakt, another page fault occurs because Kontakt hasn't been loaded into memory yet. As Kontakt loads samples, there are more page faults. Wait for a minute or two and the page faults fall off because everything Cakewalk needs has been transferred from disk to RAM (assuming you have enough RAM, of course, and ignoring the vagaries of DSD).

So the presence of hard page faults isn't a mystery, it's just how virtual memory works. Seeing page faults is not necessarily an indication of too-little RAM.

But why would there be more of them when anti-virus software is enabled? What you're seeing represents extra disk activity initiated by the AV. If you think about it, an AV program works like every other program, in that it can't read data directly from disk and must load any file it examines into memory first. And you get hard page faults.

But, you say, wouldn't that result in a soft page fault when Cakewalk subsequently requests those files, since they've already been loaded into memory by the AV? Sadly, that's not the case. Remember, the AV is intercepting CW's requests and wants to examine the files before allowing those requests to proceed. That means the AV opens each file, loads it into RAM and reads it. It tries to do this transparently so that the requesting application doesn't know it's happening. For that reason, the AV closes the files, releases the memory pages and flushes the cache so it's as if those blocks had never been loaded. When Cakewalk then finally gets to go after them, they have to be loaded again via a hard page fault. 

Which is a long-winded way of stating the obvious: real-time AV "protection" slows things down. The solution: tell the AV to keep its mitts off your sample libraries.

 

P.S. I don't believe this has anything to do with thread scheduling, but I can't be certain. When one thread is blocked (e.g. by an interrupt) other threads may or may not be able to continue executing. Since all threads share the same memory, I would expect them all to blocked by a hard page fault. But I'll defer to Noel's expertise on this question.