-
Notifications
You must be signed in to change notification settings - Fork 705
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add the condition for updating the tlb only after a miss is incurred #1807
Conversation
✔️ successful run, report available here. |
Thanks @HudaSajjad for this PR. @AngelaGonzalezMarino Can I ask you to approve it ? |
Sure, I will look at it and include it in the merged MMU |
@AngelaGonzalezMarino you can look so that we can merge this separately, and MMU unifying work can continue alongside. Thanks. |
What is the update on this? @AngelaGonzalezMarino @JeanRochCoulon |
Hi, it seems OK to me. I have tried with sv32 and sv39 configurations, both work OK (work means that Yocto boots on both of them). I don't see any performance gain either (booting time is the same). Is there a specific test I should do to see some change or benefit? Actually, I think in a way the behaviour was already the same. Without a miss, the shared TLB does not give a valid update, (itlb_req_q or dtlb_req_q need to be set in order to output a 1 in the valid flag of the itlb or dtlb update). Therefore, the TLB does not update if there is no miss, because there is no valid. Have you seen a case where this is different? |
This is already integrated in the unified MMU #1851 |
Closing this one, since @AngelaGonzalezMarino included this change in #1851 |
Problem Statement:
In the TLB module of the MMU_sv32 unit during the update and flush mode, if the flush signal is high, the TLB is flushed according to the SFENCE.VMA command. However, in the event that the flush signal is not enabled the value in the TLB module is updated regardless of whether there was a hit or a miss in the TLB. If the updated value from the shared TLB is valid one of the entries in the TLB is updated with this value.
Proposed Solution:
During the update phase while checking that the updated value is valid or not it should also be checked that the TLB was missed and only in the case that the TLB was missed should the SHARED_TLB be accessed and an update value received from it.