Right, the page table *keeps track* of the mapping, but there is no dynamic assignment of pages. There is not a point at which you could decide to assign a particular page to a particular physical page number. He want to assign particular Vaddrs on the fly to particular page numbers to ensure specific set assignments in the cache. Lisa
On Wed, Apr 8, 2009 at 5:11 PM, Gabriel Michael Black <[email protected] > wrote: > Actually, everything in SE should work about the same as in FS except > for where the page tables are stored and how they end up in the TLB. > In FS they work as they would in a real system. In SE there's a page > table structure maintained within M5 which keeps track of the mapping. > On TLB misses, instead of faulting into an operating system or doing a > hardware page table walk on x86, m5 fixes up the TLB automatically and > continues execution. If you want to change how physical addresses are > assigned, you need to look at that page table structure and the places > it's used. > > Gabe > > Quoting Lisa Hsu <[email protected]>: > > > Hi Meng-Ju, > > Unfortunately I don't think there is an easy way to do this in SE. The > > physical mapping is done in a pretty fake way, where program binaries are > > mmaped in M5. This way, a physical address read in M5 will correspond to > a > > physical address on the native machine and we can read binary files. > This > > is why the amount of Memory modeled in M5 has to exceed the total amount > of > > physical pages ever used during runtime, because we never swap out. > > > > As a result, there is no point in SE where you have a page fault and then > > have an opportunity to decide which physical page to place a page being > > brought in from disk because that was decided while M5 was setting up > > execution. > > > > I suppose you could consider adding a level of indirection to map between > > the physical addresses generated by M5 and the physical address you want > to > > use, and making sure the memory system uses the latter. > > > > Otherwise, I can't really think of a simple way to get around this unless > > you went the FS route. > > > > Lisa > > > > On Mon, Apr 6, 2009 at 1:23 PM, Meng-Ju Wu <[email protected]> wrote: > > > >> Hi all, > >> > >> I have two questions about the virtual memory implementation on M5 > >> ALPHA SE mode. > >> > >> (1) In M5, the virtual address is translated to the physical address > >> before the cache access. Now, I want to do the padding in my > >> application to control the data locality. For example, partition > >> several datasets to fit all of them into the L2 cache, and each > >> dataset is exactly mapped to its own sets in the cache. The > >> application can only see the virtual address, and the L1/L2 caches are > >> using physical address. Is it possible to do the padding to control > >> the spectral locality in application level? > >> > >> (2) If I want to control the virtual to physically address mapping in > >> the page level, where is the entry point of the M5 source codes? And > >> how to do it? > >> > >> Thanks a lot, > >> > >> Meng-Ju > >> _______________________________________________ > >> m5-users mailing list > >> [email protected] > >> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > >> > >> > > > > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > >
_______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
