Dear Zakira,

I hope you would be safe and sound at UM.

Sorry, I can't help you in your inquiry.

With warm regards,

Dr.Qayyum Shah,

U.E.T, Peshawar-Pak:

You can't obtain  this information because the cache access is dynamic and cache missing also

the problem is that you don't have only your program but also all system and others programs in your processor system.

SO you can't know when the cache misses.

As a practical matter the measurements are intrinsic to the hardware.   There are testing tools which boot up on its own RTOS and will test the system.  In other words, this is a borrow, not build situation.  But if you insist on building, here is how I would approach it, apologies in advance for the too many words:  

To Samir's point, doing this in an arbitrary live OS is considerably more tricky.

You will need to use some method to enter a non-preemptable privilege time execution state - such as you might need to happen during an interrupt service routine.  The name used to describe this execution environment will vary from OS to OS.  

In linux they call this an "atomic context" - for obvious reasons - but also if you mess up the kernel goes nuclear.  For example, you cannot call any blocking functions, and using swapped out virtual memory?  Kaboom!

There are several examples of writing ISR's for Linux - find one you like.   You may, depending on the OS, be able to use an atomic context outside of an ISR, in which case you might be able to implement a kernel module implementing a procfs interface to interrogate the test code.  that makes running the tests and getting the results easy. 

You would basically disable interrupts while your test code beats up on the RAM.  You can still use the on-CPU super high resolution timer which does still advance during an interrupt blackout.   Provided the amount of time you stall the kernel is not too long ( single digit seconds ) you should be OK.