Hi My area of research involves collecting data about the cacheLine state. I've done some modification to the old mars v0.1 code to monitor changes in the mesiCache files. With marss v0.2.1, I was hoping to port the changes over but I'm unsure about the way the cache parameters are specified and thought I'd ask.
Reading through the most recent email thread about cacheConstants.h not being used (dated Sept 30, 2011), it stated that the cacheConstant values were not used. Instead, the value was supposed to be passed in by ptl-qemu.cpp through CPUID values. However from what I can glean from the source code. the MESI_cache / shared L2 configuration uses the coherent cache, which, it seems, stores the cacheLines in the same cacheLines_/cacheLineBase class as the older version (which still #includes cacheContants.h). Nevertheless from running the experiment, it seems that the cache sizes do follow the input values specified in the config files, yet these exact same coherentCache files are being used during runtime. I would greatly appreciate any clarification. Thank you! Zhong Liang Ong ________________________________________ From: [email protected] [[email protected]] On Behalf Of [email protected] [[email protected]] Sent: Friday, September 30, 2011 12:00 AM To: [email protected] Subject: Marss86-Devel Digest, Vol 19, Issue 20 Send Marss86-Devel mailing list submissions to [email protected] To subscribe or unsubscribe via the World Wide Web, visit https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel or, via email, send a message with subject or body 'help' to [email protected] You can reach the person managing the list at [email protected] When replying, please edit your Subject line so it is more specific than "Re: Contents of Marss86-Devel digest..." Today's Topics: 1. Re: regarding multi-p2p (avadh patel) 2. Re: regarding multi-p2p (sparsh mittal) 3. Release 0.2 (avadh patel) 4. use of cache constants (sparsh mittal) 5. Re: use of cache constants (DRAM Ninjas) ---------------------------------------------------------------------- Message: 1 Date: Wed, 28 Sep 2011 09:55:59 -0700 From: avadh patel <[email protected]> To: sparsh mittal <[email protected]> Cc: marss86-devel <[email protected]> Subject: Re: [marss86-devel] regarding multi-p2p Message-ID: <cadtv7ctcvffme99-btq5am_kv48m6jq_ci1bhdwewb9edba...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" On Wed, Sep 28, 2011 at 5:59 AM, sparsh mittal <[email protected]>wrote: > Actually, I was thinking as Paul is thinking,and this may be true for > parallel workload. But what if we have multi-progammed workload? These > workloads don't share any data among different cores, so I hope in L1, they > will not need to share data. In L2 they are sharing the space but not the > data. Correct me if I am wrong. I am personally using multi-prog. workload, > that's why I was thinking of no need of coherence in L1. > > Even if you are running multi-prog workloads, kernel will share some data. For your scheme to work, you need to implement a special WT-L1 and L2 cache that will make sure that on each write cache line has to be locked in shared L2 so write update is seen as atomic and hence you serialize all memory updates for correctness. - Avadh Thanks and Regards > Sparsh Mittal > > > > > On Wed, Sep 28, 2011 at 12:10 AM, DRAM Ninjas <[email protected]>wrote: > >> Certainly you can do this, but unless I'm misunderstanding something, it >> won't actually be 'correct'. If you have multiple L1 caches, you have to >> enforce consistency on them -- which is precisely why you can only have the >> bus there be a MESI bus. If you just have all of the private caches write >> through, then who knows what value that will end up going back to memory is >> and what each processor will see as the 'right' values. >> >> From a simulation standpoint it obviously won't matter since there's no >> data involved in the memoryHierarchy objects, but I don't know if realism is >> a concern for you. >> >> >> On Wed, Sep 28, 2011 at 12:09 AM, avadh patel <[email protected]>wrote: >> >>> >>> On Tue, Sep 27, 2011 at 2:59 PM, sparsh mittal >>> <[email protected]>wrote: >>> >>>> Hello >>>> This regards to a previous discussion (copied below): >>>> >>>> 1. So can we say that for multi-core, L1 cache can be only mesi, as per >>>> code existing now. >>>> >>> >>> Now you can also use moesi cache. >>> >>>> 2. If I think of implementing p2p_multi, would you give some hint: which >>>> files/code sections would be affected (some hints you have already given >>>> below). Any precaution? >>>> >>>> Take a look at ptlsim/cache/p2p.* files. You can add a array (use >>> 'dynarray') in p2p which can store multiple upper level controllers when >>> registered. And when it receives a request, it can find 'dest' controller >>> from the array and forward request to 'dest' controller. >>> >>> - Avadh >>> >>> Summary of my experiments: >>>>> 1. The configuration with L1 =mesi runs fine, which you pointed out >>>>> 2. The config with L1=write-through, and L1-L2 as mesi does not work >>>>> (copied below, item 1, reduced log file attached) >>>>> >>>> >>>> I looked at the configuration and logfile and the reason its not working >>>> is because the bus interconnect is designed for MESI only. So when you >>>> attached write-through caches it doesnt work because bus is waiting for >>>> snoop response from all connected controllers. And WT caches are not >>>> designed to perform snoop operations and send response back, so they ignore >>>> the request and dont respond anything. (Look for 'responseReceived' in >>>> logfile, it at the end). Due to this behavior the cores wait for cache >>>> request to complete and never make any progress. >>>> >>>> 3. The config with L1=write-through, and L1-L2 as p2p does not work >>>>> (copied below, item 2, log file has almost nothing) >>>>> >>>> >>>> In this configuration, first thing is that you used 'p2p' interconnect >>>> to attach all L1 I,D caches and L2 cache, but 'p2p' supports connecting >>>> only >>>> 2 controllers. >>>> >>>> The solution to this issue is to create a new interconnect module that >>>> allows you to send messages directly to lower cache and send response back. >>>> To develop such a module should not take too long as you are not going to >>>> buffer any request, you'll just pass the request from source to destination >>>> just like in 'p2p' interconnect. But unlike 'p2p' this interface will >>>> support multiple Upper and single Lower interconnect. I suggest you take a >>>> look at p2p interconnect design on how it passes the message from one >>>> interconnect to other. And create a new interconnect, lets call it >>>> 'p2p_multi', that allows multiple upper connections. >>>> >>>> Thanks and Regards >>>> Sparsh Mittal >>>> >>>> >>>> >>>> _______________________________________________ >>>> http://www.marss86.org >>>> Marss86-Devel mailing list >>>> [email protected] >>>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >>>> >>>> >>> >>> _______________________________________________ >>> http://www.marss86.org >>> Marss86-Devel mailing list >>> [email protected] >>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://www.cs.binghamton.edu/mailman/private/marss86-devel/attachments/20110928/579108bf/attachment-0001.html> ------------------------------ Message: 2 Date: Wed, 28 Sep 2011 12:54:29 -0500 From: sparsh mittal <[email protected]> To: avadh patel <[email protected]> Cc: marss86-devel <[email protected]> Subject: Re: [marss86-devel] regarding multi-p2p Message-ID: <caf9m4ziwkyzmzl8wg+ve43_rnwkuyxea6n5cj1tnlkuqz4f...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" On Wed, Sep 28, 2011 at 11:55 AM, avadh patel <[email protected]> wrote: > > Even if you are running multi-prog workloads, kernel will share some data. > For your scheme to work, you need to implement a special WT-L1 and L2 cache > that will make sure that on each write cache line has to be locked in shared > L2 so write update is seen as atomic and hence you serialize all memory > updates for correctness. > > I have done some implementation of multip2p. 1. If I only take user-stats, still do I need to implement what you said above? 2. Now, my understanding of how to apply your above comment is: when L1 cache writes to L2, I need to make sure a. No other L1 cache is updating L2 at that time or no other L1 can replace that block before it is written. b. Something else? Thanks a lot for these insights. > - Avadh > > Thanks and Regards >> Sparsh Mittal >> >> >> >> >> On Wed, Sep 28, 2011 at 12:10 AM, DRAM Ninjas <[email protected]>wrote: >> >>> Certainly you can do this, but unless I'm misunderstanding something, it >>> won't actually be 'correct'. If you have multiple L1 caches, you have to >>> enforce consistency on them -- which is precisely why you can only have the >>> bus there be a MESI bus. If you just have all of the private caches write >>> through, then who knows what value that will end up going back to memory is >>> and what each processor will see as the 'right' values. >>> >>> From a simulation standpoint it obviously won't matter since there's no >>> data involved in the memoryHierarchy objects, but I don't know if realism is >>> a concern for you. >>> >>> >>> On Wed, Sep 28, 2011 at 12:09 AM, avadh patel <[email protected]>wrote: >>> >>>> >>>> On Tue, Sep 27, 2011 at 2:59 PM, sparsh mittal <[email protected] >>>> > wrote: >>>> >>>>> Hello >>>>> This regards to a previous discussion (copied below): >>>>> >>>>> 1. So can we say that for multi-core, L1 cache can be only mesi, as per >>>>> code existing now. >>>>> >>>> >>>> Now you can also use moesi cache. >>>> >>>>> 2. If I think of implementing p2p_multi, would you give some hint: >>>>> which files/code sections would be affected (some hints you have already >>>>> given below). Any precaution? >>>>> >>>>> Take a look at ptlsim/cache/p2p.* files. You can add a array (use >>>> 'dynarray') in p2p which can store multiple upper level controllers when >>>> registered. And when it receives a request, it can find 'dest' controller >>>> from the array and forward request to 'dest' controller. >>>> >>>> - Avadh >>>> >>>> Summary of my experiments: >>>>>> 1. The configuration with L1 =mesi runs fine, which you pointed out >>>>>> 2. The config with L1=write-through, and L1-L2 as mesi does not work >>>>>> (copied below, item 1, reduced log file attached) >>>>>> >>>>> >>>>> I looked at the configuration and logfile and the reason its not >>>>> working is because the bus interconnect is designed for MESI only. So when >>>>> you attached write-through caches it doesnt work because bus is waiting >>>>> for >>>>> snoop response from all connected controllers. And WT caches are not >>>>> designed to perform snoop operations and send response back, so they >>>>> ignore >>>>> the request and dont respond anything. (Look for 'responseReceived' in >>>>> logfile, it at the end). Due to this behavior the cores wait for cache >>>>> request to complete and never make any progress. >>>>> >>>>> 3. The config with L1=write-through, and L1-L2 as p2p does not work >>>>>> (copied below, item 2, log file has almost nothing) >>>>>> >>>>> >>>>> In this configuration, first thing is that you used 'p2p' interconnect >>>>> to attach all L1 I,D caches and L2 cache, but 'p2p' supports connecting >>>>> only >>>>> 2 controllers. >>>>> >>>>> The solution to this issue is to create a new interconnect module that >>>>> allows you to send messages directly to lower cache and send response >>>>> back. >>>>> To develop such a module should not take too long as you are not going to >>>>> buffer any request, you'll just pass the request from source to >>>>> destination >>>>> just like in 'p2p' interconnect. But unlike 'p2p' this interface will >>>>> support multiple Upper and single Lower interconnect. I suggest you take a >>>>> look at p2p interconnect design on how it passes the message from one >>>>> interconnect to other. And create a new interconnect, lets call it >>>>> 'p2p_multi', that allows multiple upper connections. >>>>> >>>>> Thanks and Regards >>>>> Sparsh Mittal >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> http://www.marss86.org >>>>> Marss86-Devel mailing list >>>>> [email protected] >>>>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >>>>> >>>>> >>>> >>>> _______________________________________________ >>>> http://www.marss86.org >>>> Marss86-Devel mailing list >>>> [email protected] >>>> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://www.cs.binghamton.edu/mailman/private/marss86-devel/attachments/20110928/e22f6f3e/attachment-0001.html> ------------------------------ Message: 3 Date: Wed, 28 Sep 2011 11:24:08 -0700 From: avadh patel <[email protected]> To: MARSS List <[email protected]> Subject: [marss86-devel] Release 0.2 Message-ID: <CADtv7CTkMJUxfqtxOuE8L5daf=rfqe3y696ddvhdz_+04eo...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Hi Everyone, I am very glad to announce long due 0.2 release of Marss. Here are some of the highlights of this release: * New Statistics Collection Framework * New Modular Core, Cache and Interconnect Framework * Upgraded Qemu to 0.14.1 release [from Adnan] * Atom Core Model * MOESI Cache Model * Switch Interconnect Model * Machine Configuration for easy designs * Periodic Stats Dump support [from Paul] * Better Utility scripts [from Paul] * Bug fixes related to QEMU interface Its been a long time since last release but we are glad to provide more stable and modular framework that will enable faster development of new core and cache modules. You can download the tar from here: https://github.com/avadhpatel/marss/tarball/0.2 With this I have merged all the changes from core-models to master branch and all bug fixes will apply to master branch only. We are looking to compile a list of features for next (0.3) release, if you have something in mind or you can contribute please send us an email. Few things I have in mind are: * Better debugging support (Please send your suggestions) * Multi-threaded simulations for higher number of cores * Update Qemu to 0.15 or the latest stable release Once again thanks for your contributions and bug reports. - Avadh -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://www.cs.binghamton.edu/mailman/private/marss86-devel/attachments/20110928/325fe3e1/attachment-0001.html> ------------------------------ Message: 4 Date: Wed, 28 Sep 2011 17:49:46 -0500 From: sparsh mittal <[email protected]> To: marss86-devel <[email protected]> Subject: [marss86-devel] use of cache constants Message-ID: <CAF9M4Zi=owBv9uwbfCWT9FVGCqO+VPZdV_qWqK3d=ylw0ys...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" Hello I was trying to understand what is the use of constants defined in the cacheConstants.h, now when new config. mechanism is in place. When a machine is specified at run time, these constants differ from that value. These constants are used in ptl-qemu.cpp file. Thanks and Regards Sparsh Mittal -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://www.cs.binghamton.edu/mailman/private/marss86-devel/attachments/20110928/bbedd5bb/attachment-0001.html> ------------------------------ Message: 5 Date: Thu, 29 Sep 2011 01:42:37 -0400 From: DRAM Ninjas <[email protected]> To: sparsh mittal <[email protected]> Cc: marss86-devel <[email protected]> Subject: Re: [marss86-devel] use of cache constants Message-ID: <CAG_SxBPS_nTEqkxeMM1X=qCra=mjsj5m60dfqx4ehn_mwb0...@mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" The majority (or perhaps all?) of them aren't used anymore with the new configuration mechanism. Perhaps a few miscellaneous ones like MEM_REQ_NUM or whatever, but those aren't that important. On Wed, Sep 28, 2011 at 6:49 PM, sparsh mittal <[email protected]>wrote: > Hello > I was trying to understand what is the use of constants defined in the > cacheConstants.h, now when new config. mechanism is in place. When a machine > is specified at run time, these constants differ from that value. > These constants are used in ptl-qemu.cpp file. > Thanks and Regards > Sparsh Mittal > > > > _______________________________________________ > http://www.marss86.org > Marss86-Devel mailing list > [email protected] > https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://www.cs.binghamton.edu/mailman/private/marss86-devel/attachments/20110929/5f449487/attachment-0001.html> ------------------------------ _______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel End of Marss86-Devel Digest, Vol 19, Issue 20 ********************************************* _______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
