This is a long run question but do you have any statistics about the amount of page faults that your software would generate ? Or at least the what would be the variables that could increase the number of page faults ?
I’m not part of the GlassWire team so I don’t know how they design their application. But I do know that your question probably can’t be satisfactorily answered without knowing why you want that information. So without knowing what question you are trying to answer then here’s a generic overview of page fault causes. It will be useful for anyone else wondering about such issues…
Page faults are largely determined by your system configuration and the memory management processes in your operating system. Page faults are largely out of the control of the application. In general, the more memory you have installed then, all other things being equal, the fewer page faults will occur.
The Basics of Page Faults
… one of the most common problems when dealing with virtual memory – the Page Fault. A page fault occurs when a program requests an address on a page that is not in the current set of memory resident pages.
If your system has no virtual memory then you will get no page faults because all accessible memory pages will be loaded in memory.
Now this is where it gets more complicated because although the above definition is the primary meaning, it is not the only meaning. There are at least three categories of page fault and what I said above is only true for such hard page faults. They are called hard page faults because they are primarily caused by your hardware configuration. If you get hard page faults then you can stop them by installing enough physical memory.
Here’s a broader definition of page faults:
Wikipedia
A page fault (sometimes called #PF, PF or hard fault) is a type of exception raised by computer hardware when a running program accesses a memory page that is not currently mapped by the memory management unit (MMU) into the virtual address space of a process.
This definition allows for at least three types of access exception:
- Hard page fault: The page is not loaded in memory and has to be loaded from another medium, e.g. from disk storage.
- Soft page fault: The page is loaded in memory but is not available to be accessed by that process, for example:
- the page has been loaded for another process and the requesting process doesn’t yet have access to it.
- the page has been marked as free but the data has not yet been overwritten so access to it can be restored
- Invalid page fault: The request is invalid for some reason such as that the requested page does not exist.
Note that I don’t say that page faults are errors. Only the invalid page fault is an error. Hard and soft page faults are simply part of the normal operation of memory management.
More page faults isn’t necessarily bad, just as less page faults isn’t necessarily better, e.g. if the page faults are few but all invalid then that is bad. More page faults usually means that your system is making efficient use of the configuration provided. In other words, the running processes require more memory than is available so the memory management processes are ensuring they all receive timely access to the data they need.