0

I am working on hardware performance counter (HPCs) and I seek to use these counters to measure some events accurately.

I have found that the non-determinism in hardware performance counter (inaccurate) could be due to page faults occurred at run time. The number of page faults directly impacts the instruction and branch count.

My question: Is there a way to predict (or calculate) the number of page faults using static analysis of source code? if not, Is this possible dynamically?

0

You could definitely produce a log of all page faults but you will not be able to predict them reliably. Just turn off virtual memory and make sure your software fits in RAM, or better yet L2. Maybe zram would help. Also set the nice value and use a real time OS if you want better results.

1
  • My case is very critical to time overhead, so I cannot use additional modules or any 3rd party packages. I just want to count or predict page faults statistically so that no redundant instructions or something else. – husin alhaj ahmade Dec 2 '18 at 6:13
0

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_CURRENT and MCL_FUTURE flags set. This does three things:

  1. It prevents any memory mapped by the process from being swapped out, ever (well, at least until you call munlockall()).
  2. 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.
  3. 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).

2
  • Yes thank you very much for your valuable clarification What you said is quite true. I tried these System Calls in my Ubuntu OS and after that I started looking for another way, because in this case the method I work on will not be portable. I have not yet reached a solution but I am close to giving up. Because most of professors I have asked have told me that in the current situation with the complex architecture and the existence of the cache memory ... what you are looking for may be not possible. – husin alhaj ahmade Dec 3 '18 at 21:11
  • It ends up being a case where you're looking at controlling sufficiently low-level behavior of the OS that it realistically can't be truly portable. mlockall() is actually pretty portable though, pretty much all modern UNIX systems support it. – Austin Hemmelgarn Dec 4 '18 at 15:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.