I'd be in favor of the name change from CPU to cores but would prefer that the concept of a CPU object including a core and a cache be left to Python configurations (as Gabe said). Who knows, it might become commonplace for a CPU to have a L1 and a L2 cache and then you'd have to add that interface to the object. I'd have similar thoughts for defining a cluster.
On Wed, May 30, 2012 at 3:24 PM, Andreas Hansson <[email protected]>wrote: > Indeed, as Ali clarified, the CPU -> core is the fist part. The rest is > just convenience "containers" pertaining to the object hierarchy and > bundling. For example, I might want to create an AndreasCPU which is a > SimObject that has a few cores + caches, and that Python and C++ class > would enable me to create a better way of describing these hierarchies. I > could also add stats to this new object that sees both the cores and caches. > > Thanks, > > Andreas > ________________________________________ > From: [email protected] [[email protected]] On Behalf Of > Ali Saidi [[email protected]] > Sent: Wednesday, May 30, 2012 11:09 PM > To: [email protected] > Subject: Re: [gem5-dev] Core, CPU, cluster in gem5 > > I think what Andreas was proposing is to make the thing that > executes instructions a core and add a new container class that is a CPU > which includes pointers to the various caches the CPU is part of? > > > Thanks, > > Ali > > On 30.05.2012 16:42, Steve Reinhardt wrote: > > > Well, > when I was a kid, most CPUs didn't have caches, and "core" was what > > > old-timers used before they invented DRAM. ;-) So I guess I'm not all > > > that sympathetic to the objections to the current naming. > > > > In > particular, I think CPU is a pretty ambiguous term, so I'm not keen on > > > saying that we currently have it wrong. That said, CPU is a pretty > > > ambiguous term, so I'm fine with renaming what we now call a CPU to be > a > > core, as I think that is less ambiguous. > > > > Beyond that, I'm a bit > skeptical of being too rigid about other names. We > > don't always have > caches with our cores, e.g., when fat-forwarding with > > AtomicSimple. > There are other configurations where each CPU has its own > > L2. And > internally to AMD we have configurations that mimic Bulldozer core > > > pairs, which is yet another wrinkle. > > > > Also, I'm not clear on how > renaming things makes the "get a pointer to my > > L1" operation easier. > > > > > In general I'm supportive of making configuration easier though, so > I'm not > > necessarily opposed to the idea... the benefit just isn't > clear to me, > > probably because I don't understand Andreas's use cases > in detail. > > > > Steve > > > > On Wed, May 30, 2012 at 12:57 PM, Ali Saidi > <[email protected]> wrote: > > > >> I think both symmetric and asymmetric > systems need to be configurable. The latter is going to become more and > more common in the future. Thanks, Ali Sent from my ARM powered mobile > device On May 30, 2012, at 3:42 PM, Gabriel Michael Black > <[email protected] [6]> wrote: > >> > >>> I'd like to see things still > architected primarily around Cores (which > >> is a better name, I think) > than CPUs and for CPUs to be a configuration convenience primarily used > at the python level. We don't want to force people into having CPUs set > up in a particular way or with particular components by baking certain > flavors of them into the rest of the simulator, but the idea in general > seems pretty reasonable. Or in other words, I'd like to see this make > things easier for the 90% who have normal looking CPUs while not making > things any harder for the 10% who have some wacky scratch pad memory or > an asymmetric cache hierarchy or an L2 on the CPU or whatever. > >> > >>> > Gabe Quoting nathan binkert <[email protected] [1]>: > >>> > >>>> I like > the idea. Can we rename BaseCache to Cache while we're at it? I'm not > going to volunteer, but the best way to make this work IMHO is to write > a script that does the searching/replacing and make that one patch on > its own. Then create another patch that fixes up any mistakes. This > serves two purposes. First, you can just drop the old patch and > regenerate it whenever you update your script, and second, all we need > to do is review your script and the second patch. We've done this sort > of thing many times in the past and to be honest, it's not that hard. > The hardest part is dealing with the fact that scripts and stat names > end up getting affected. Nate > >>>> > >>>>> I am sure there are lots of > ideas and opinions about the modelling of > >> a core vs CPU vs cluster, > and I am keen to know how people feel about doing some major re-naming > and introduce some new levels of hierarchy in the world of gem5 models. > This change also needs to be coupled with updates to how cores are > enumerated, numbered, initialised, modelling of power states, etc. > > > > > _______________________________________________ > > gem5-dev mailing > list > > [email protected] > > http://m5sim.org/mailman/listinfo/gem5-dev > > > > > Links: > ------ > [1] mailto:[email protected] > [2] > mailto:[email protected] > [3] > http://m5sim.org/mailman/listinfo/gem5-dev > [4] > mailto:[email protected] > [5] > http://m5sim.org/mailman/listinfo/gem5-dev > [6] > mailto:[email protected] > [7] mailto:[email protected] > [8] > http://m5sim.org/mailman/listinfo/gem5-dev > [9] mailto:[email protected] > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > > > -- IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > -- - Korey _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
