Searched hist:12442 (Results 1 - 3 of 3) sorted by relevance
/gem5/src/systemc/core/ | ||
H A D | kernel.cc | 13130:e67ad27f0858 Wed Aug 29 03:05:00 EDT 2018 Gabe Black <gabeblack@google.com> systemc: Track the module who's end_of_elaboration callback we're in. Change-Id: Ib5fe3232cfea26df0c3396c583fd80da429cbdd5 Reviewed-on: https://gem5-review.googlesource.com/c/12442 Reviewed-by: Gabe Black <gabeblack@google.com> Maintainer: Gabe Black <gabeblack@google.com> |
/gem5/src/mem/ | ||
H A D | page_table.cc | 12442:e003b72b46ac Fri Dec 22 22:21:00 EST 2017 Gabe Black <gabeblack@google.com> mem: Track TLB entries in the lookup cache as pointers. Using the architectural page table on x86 and the functional page table on ARM, both with the twolf benchmark in SE mode, there was no performance penalty for doing so, and again possibly a performance improvement. By using a pointer instead of an inline instance, it's possible for the actual type of the TLB entry to be hidden somewhat, taking a step towards abstracting away another aspect of the ISAs. Since the TLB entries are no longer overwritten and now need to be allocated and freed, this change introduces return types from the updateCache and eraseCacheEntry functions. These functions will return the pointer to any entry which has been displaced from the cache which the caller can either free or ignore, depending on whether the entry has a purpose outside of the cache. Because the functional page table stores its entries over a longer time period, it will generally not delete the pointer returned from those functions. The "architechtural" page table, ie the one which is backed by memory, doesn't have any other use for the TlbEntrys and will delete them. That leads to more news and deletes than there used to be. To address that, and also to speed up the architectural page table in general, it would be a good idea to augment the functional page table with an image of the table in memory, instead of replacing it with one. The functional page table would provide quick lookups and also avoid having to translate page table entries to TLB entries, making performance essentially equivalent to the functional case. The backing page tables, which are primarily for consumption by the physical hardware when in KVM, can be updated when mappings change but otherwise left alone. If we end up doing that, we could just let the ISA specific process classes enable whatever additional TLB machinery they need, likely a backing copy in memory, without any knowledge or involvement from the ISA agnostic class. We would be able to get rid of the useArchPT setting and the bits of code in the configs which set it. Change-Id: I2e21945cd852bb1b3d0740fe6a4c5acbfd9548c5 Reviewed-on: https://gem5-review.googlesource.com/6983 Maintainer: Gabe Black <gabeblack@google.com> Reviewed-by: Brandon Potter <Brandon.Potter@amd.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com> |
H A D | page_table.hh | 12442:e003b72b46ac Fri Dec 22 22:21:00 EST 2017 Gabe Black <gabeblack@google.com> mem: Track TLB entries in the lookup cache as pointers. Using the architectural page table on x86 and the functional page table on ARM, both with the twolf benchmark in SE mode, there was no performance penalty for doing so, and again possibly a performance improvement. By using a pointer instead of an inline instance, it's possible for the actual type of the TLB entry to be hidden somewhat, taking a step towards abstracting away another aspect of the ISAs. Since the TLB entries are no longer overwritten and now need to be allocated and freed, this change introduces return types from the updateCache and eraseCacheEntry functions. These functions will return the pointer to any entry which has been displaced from the cache which the caller can either free or ignore, depending on whether the entry has a purpose outside of the cache. Because the functional page table stores its entries over a longer time period, it will generally not delete the pointer returned from those functions. The "architechtural" page table, ie the one which is backed by memory, doesn't have any other use for the TlbEntrys and will delete them. That leads to more news and deletes than there used to be. To address that, and also to speed up the architectural page table in general, it would be a good idea to augment the functional page table with an image of the table in memory, instead of replacing it with one. The functional page table would provide quick lookups and also avoid having to translate page table entries to TLB entries, making performance essentially equivalent to the functional case. The backing page tables, which are primarily for consumption by the physical hardware when in KVM, can be updated when mappings change but otherwise left alone. If we end up doing that, we could just let the ISA specific process classes enable whatever additional TLB machinery they need, likely a backing copy in memory, without any knowledge or involvement from the ISA agnostic class. We would be able to get rid of the useArchPT setting and the bits of code in the configs which set it. Change-Id: I2e21945cd852bb1b3d0740fe6a4c5acbfd9548c5 Reviewed-on: https://gem5-review.googlesource.com/6983 Maintainer: Gabe Black <gabeblack@google.com> Reviewed-by: Brandon Potter <Brandon.Potter@amd.com> Reviewed-by: Jason Lowe-Power <jason@lowepower.com> Reviewed-by: Anthony Gutierrez <anthony.gutierrez@amd.com> |
Completed in 31 milliseconds