Hello Srinath, I don't think there is any way do what you want to do. On older processors there was a partial wc buffer write event (I think) but this event doesn't exist on current processors. And the event didn't tell how many bytes were written, just the number of times a partial write occurred. Sorry, Pat
Is there a way to retrive data addresses (virtual or physical) accessed by loads and stores (I am specifically looking for non-temporal stores) ? I was initially using PIN to do that and the performance was terrible. Is there a way to get that info from the hardware directly, say at the time of instruction retirement or something ?
Is there any meta information (possibly through hardware counters) that I can retrieve from Write Combing Buffers (WCB) (I mmap-ed by address space to WC mode to bypass cache) ?
My question was not about performance. I am trying to save some cache space by bypassing writes that don't need any locality, directly into a storage device. Similar to bypassing framebuffers into the graphics device.
One of the problems I am facing is that, I need to provide some correctness guarantees. I need to verify if the cache-lines flushed from the WCBs have all reached the destination. But to do that I need some information from the processor side such as
1) physical address of cache lines flushed from WCB
2) Number of bytes
3) Atlleast number of partial/full lines flushed
Any combination of 1), 2) or 3) is fine.
Is there a way for me retrieve such information somewhere from the processor ?
As you probably know, non-temporal load/store instructions (movntps, movntdq, etc) are a way to bypass the cache on read and write.
Since non-temporal stores are weakly ordered before using the data you need to issue mfence/lfence/sfence (depending on what you are doing with the data, most likely sfence in your case).
Those fencing instructions are the only guarantee that the data has reached the destination before you use it.
As far as I know, the metrics that you are looking for are not available as CPU counters -- perhaps they can be observed through ITP debugging but I am not sure about that, and such hardware is extremely expensive anyway.