On 7/6/2023 1:47 PM, Khan Shaikhul Hadi via gem5-users wrote:
In my configuration I used CPUTypes.O3 and PrivateL1SharedL2CacheHeirarchy to check how clflush and fence impacts the timing of workload. In my workload I run 10,000 iteration to update an array value, 200 updates per thread. In workload, I have :for( ;index <end_index-1;index++){ ARR[index]=thread_ID; ARR[index+1]=thread_ID; FENCE; }to simulate two consecutive localized write operations and see the impact of the fence. Insertion of FENCE ( macro to insert mfence ) increase execution time by 24%. In second scenario, I have :for( ;index <end_index-1;index++){ ARR[index]=thread_ID; FLUSH(&ARR[index]); FENCE; }Where FLUSH (macro for _mm_clflush) should take more time to complete than ARR[index+1]=thread_ID as this memory update should be highly localized and flush needs to get acknowledgement from all levels of cache before complete. So, FENCE should have much more penalty for flush compared to write operation. So, I was hoping to see a high execution time increase for insertion of fences in the second scenario. But insertion of the fence only increases 2% execution time which is counter intuitive. Can anyone explain why I'm seeing this behaviour ? As far as I understand, the memory fence should let the following instruction execute after all previous instructions are completed and removed from the store buffer in which case clflush should take more time than regular write operation.
Sorry I am only now seeing this ... IIRC from my work on improving cache write back / flush behavior, the gem5 implementation considers the flush complete when the operation reaches the L1 cache - similar to what happens with stores. I agree that from a timing standpoint this is wrong, which is why I undertook some substantial surgery. I need to forward port to more recent releases, do testing, etc., but in principle have a solution that: - Gives line flush instructions timing where they are not complete until any write back makes it to the memory bus. - Deals with the weaker ordering of clwb and clflushopt (which required retooling the store unit queue processing order). - Supports invd, wbinvd, and wbnoind in addition to the line flush operations. Not sure when I will be able to accomplish putting these together as patches for the powers that be to review ... Regards - Eliot Moss _______________________________________________ gem5-users mailing list -- gem5-users@gem5.org To unsubscribe send an email to gem5-users-le...@gem5.org
