It sounds like you've got something you need to do in hard real-time. The correct way to ensure in such a case that page faults won't matter is not to try to predict them (which is not realistically possible), but to manage when and where page faults occur.
The simplest way to do this on POSIX compliant and POSIX-like systems is to call the
mlockall() function from libc on startup with both the
MCL_FUTURE flags set. This does three things:
- It prevents any memory mapped by the process from being swapped out, ever (well, at least until you call
- It forcibly faults in all currently mapped pages. Together with the first point, this means that no access to mapped memory regions will generate a page fault.
- It forcibly faults in any newly mapped pages when they get mapped. This means that any calls that allocate memory will trigger exactly the number of page faults required to get the contents of that memory region into memory, and subsequent access after the allocation finishes will not trigger any page faults.
Note that this just solves things for your program. You may still have interference from other code running on the system, but there is unfortunately not much you can do about that (except running with real-time scheduling priorities, but that too won't help much).