On Fri, Oct 21, 2011 at 2:15 PM, Gabriel Michael Black < [email protected]> wrote:
> Ok, so the new API is that the system manages physical pages, the process > manages virtual pages, the page table glues them together, and there is/are > function(s) on the process object which tie it all together? For the most part, this isn't really new... the system has always managed physical pages, the process has always managed virtual addresses, and the page table has always managed mappings. (Though the process "manages" virtual address mostly by making its variables like mmap_start and mmap_end public and letting whoever wants to muck with them.) The problem is that before the page table didn't deal only with mappings, it also had this ungainly "allocate()" method that dealt with both mappings and physical pages; I'm just cleaning it up so that the page table deals *only* with mappings, and if you want to do something that involves both mappings and physical pages, you have to go to the process object, which is the logical point where you know about both the page table and the system together. > That makes sense. I'll think about how that fits with the whole > workload/address space thing I'd like to do at some point and how that extra > level of abstraction would fit, but no problems leap out at me. > It's not an extra level of abstraction, from my perspective, it's just cleaning up some code that didn't properly obey existing conceptual boundaries. I don't know if it will interfere with what you're doing practically, but conceptually I can't see how it could do anything but make life easier, as it decouples two objects that were previously coupled. > I'll have to look at the pid thing and remind myself what it's used for. > Maybe we can get rid of it too. It's just used to populate the TLB entry... my guess is that it might matter in cases where you have multiprogrammed workloads running on an SMT core where threads from different address spaces have to share a TLB. Steve _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
