Thanks Steve. I was looking at the way pages are allocated in memory. (SE mode). The page_table.cc allocate() calls updates the PTE with the PPN obtained from calling process->system->new_page(). In the system.cc code, the new_page() simply increments the page_ptr and returns the new addr. (checking if its within the range of physmem)
now I want to add this new memory module and allocate some pages in the second module, whereas some in the first. so I could have a page_ptr per memory module, and return a addr offset-ed by the start of the new memory module. When the memory request packet is generated, it should have the address corresponding to a page in the second memory module. will this work as I understand it. Or could you suggest a better solution? thanks, Sujay On Sat, 2009-10-31 at 16:39 -0700, Steve Reinhardt wrote: > Either one of those should work (I think)... #2 is obviously easier. > The automatic address-range-setting code should cause the bus that's > between the L1(s) and the L2s to figure out which address range is > behind which L2 and direct the requests to the proper cache. > > Steve > > On Sat, Oct 31, 2009 at 4:27 PM, Sujay Phadke <[email protected]> > wrote: > Thanks Steve. I was thinking of: > > 1. adding a second port to L2 on the memside and connecting a > second memory object on that port. (sequential no interleaved > as ali pointed out). Can I connect this to a new bus to which > I connect the second memory object? > > 2. Or can I have 2 L2 caches each connected to a memory > object. I want different properties (like bandwidth) for the 2 > busses. > > --- L2 --- mem0 (0x0-0xFFFFFFF) > > --- L2 --- mem1 (0x10000000-0x2FFFFFFF) > > would the 2 L2's be seen as logically 1 larger L2? Which piece > of code sets the address range here? > > Thanks for your help > > Sujay > > > From: Steve Reinhardt > Sent: Saturday, October 31, 2009 7:18 PM > To: M5 users mailing list > Subject: Re: [m5-users] adding another bus and memory module > > > > I can't speak to the Ruby side of things, but for the native > M5 memory system, if my mental model of what you are wanting > to do is correct, I don't see any major problems. You can't > connect the existing cache model to more than one bus on each > side though, so a lot depends on how you solve that problem > (and you can't solve it by inserting bridges, since coherence > does not work across a bridge). > > Steve > > On Sat, Oct 31, 2009 at 4:01 PM, Ali Saidi <[email protected]> > wrote: > If the memory was interleaved I think it would be a > pain, however if > the memory was sequential (e.g. 0x0-0xFFFFFFF, > 0x10000000-0x2FFFFFFF) > it will probably just work. However, I haven't tried > it so I make no > guarantees. > > Ali > > > On Oct 31, 2009, at 5:40 PM, Sujay Phadke wrote: > > > > > anyone on this? > > > > -------------------------------------------------- > > From: "Sujay Phadke" <[email protected]> > > Sent: Thursday, October 29, 2009 5:59 PM > > To: <[email protected]> > > Subject: [m5-users] adding another bus and memory > module > > > >> Hello, > >> I want to simulate a system which has 2 different > main memory > >> modules > >> and 2 buses which connect it to the L2, with > different address > >> ranges. > >> (something like a dancehall). Is it straightforward > to do this or > >> would > >> it affect the coherency protocols, or something > else in the system? > >> > >> Secondly, would the changes I make be any different > if I use the ruby > >> models instead of the inbuilt dram models? > >> > >> thanks, > >> Sujay > >> > >> > >> _______________________________________________ > >> 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 > > > > > ______________________________________________________________ > _______________________________________________ > 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 _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
