So do you mind if I push this, Gabe? Or do you have further questions or concerns?
Steve On Fri, Oct 21, 2011 at 2:40 PM, Steve Reinhardt <[email protected]> wrote: > > > 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
