Let's add it to the main repository. I think once it becomes part of the repo, users will keep it up to date.

--
Nilay

On Mon, 4 Nov 2013, Ali Saidi wrote:

Seems like we’ve again petered out on this. I think it would be great to have a stable working power model for gem5. Does anyone want to volunteer to maintain the code? If we wanted to give it a try perhaps we could add the code to the repository and if it doesn’t get maintained/updated within 6 months we can delete it?

Ali


On Oct 17, 2013, at 7:30 PM, nathan binkert <[email protected]> wrote:

Not sure what has been decided here, but if nothing has been decided, I'd
like to say that ext is the wrong place for this code. Either gem5 adopts a
true fork of mcpat, puts it in src/power, adds regressions for it, etc. or
it goes in a separate repo with EXTRAS.

If you look at ext, it is really for external packages that never really
change. They're there because the packages themselves aren't found in
normal distributions and gathering the code would be prohibitive.
Essentially, we drop things into ext and forget about them.

If we want to keep a gem5 fork of mcpat up to date, then we can't forget
about it and we shouldn't hide it. It should be in the main source tree and
part of the normal build/regression process. I see only one major downside:
it's just more code to maintain (we have a dram simulator in the tree that
has basically been rotting for a decade).

If nobody wants to step up to maintain the power model, then I'd argue that
it should go into EXTRAS and if someone wants to use it on a more modern
version of gem5, then it can be updated on demand.

Nate

Thanks Tony for posting this initial patch. I know it has
been a few weeks, but want to restart this discussion.
We would like to include this version of McPAT directly
into gem5 so that we can keep it "in sync" with the
gem5 output. We fear that if we move it to a separate
source tree, it will become stale with the constantly
evolving gem5 statistics and configurations. There are
also secondary benefits from AMD's perspective in keeping
it the same respository that I'd rather not get into.
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev


_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to