diff options
author | Gabe Black <gabeblack@google.com> | 2017-12-22 19:21:30 -0800 |
---|---|---|
committer | Gabe Black <gabeblack@google.com> | 2018-01-15 22:36:41 +0000 |
commit | b8b13206c8d45cdcc16157d137845706bae915dd (patch) | |
tree | 646ceec50e38c2dd41614bd2ccf05e91adc0213b /MAINTAINERS | |
parent | 3e8d76e2e23ab23d68e569e9b2c4498a06c19f59 (diff) | |
download | gem5-b8b13206c8d45cdcc16157d137845706bae915dd.tar.xz |
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>
Diffstat (limited to 'MAINTAINERS')
0 files changed, 0 insertions, 0 deletions