Re: [gem5-users] Affect of memory violations on IPC
Hi, Very interesting observation. There are several explanations here. First, you may want to look at branch mispredictions. The pipeline flushes due to memory order violations may be shadowed by flushes due to branch mispredictions. You may want to increase your LSQ size to allow more inflight memory instructions. Finally, is memory order violations the bottleneck? For example, you can look at your potential ILP of your apps and cache misses. On Mon, Dec 9, 2019 at 1:08 PM Kamran Hasan wrote: > Hello, > > I've been wondering how memory violations between load store pairs affect > ipc and found that reducing violations by >90% results in an IPC increase > of less than 5% across many different benchmarks. The results seem pretty > counter intuitive to me as I thought the overhead of flushing the pipeline > and restarting execution would be steep. > > Here was my experimental setup: I have two versions of gem5. The first one > is straight from the repo with no changes, and uses storesets for its > memory dependance prediction. The second version is blind speculation only > has one change from the default version which is that it always returns "no > violation" when asked for a memory dependence prediction. I did this by > always returning 0 in the checkInst function in store_set.cc. Both > codebases were compiled into X86/gem5.fast and both ran the same 11 > programs from Mibench. I used the default O3 parameters so the > architecture is a 8 wide superscalar machine with a 192 ROB, 256 registers, > and 32 LQ/32SQ. Programs ran for 10M instr after fast forwarding 50M > instructions. > > > I then looked at the number of memory violations and the IPC for all the > runs and only crc, sha and dijkstra got meaningful IPC gains while the > other 8 programs did not see a benefit even though number of memory > violations were dramatically reduced. Results are here: > https://pastebin.com/raw/HhUKMha5 > > So my question is does gem5 not penalize a memory order violation as > heavily as a branch misprediction? Or is the overhead of recovering from a > memory violation truly not that big in practice? I would appreciate any > insight that could help me reconcile what I'm seeing in the experimental > data with my intuition > > > ___ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
[gem5-users] gem5 stable release proposal [PLEASE VOTE!]
Hi all, As many of you have seen on gem5-dev, we are going to be adding a "stable" version of gem5. Below is the current proposal. There are a couple of points below where there has not been general consensus reached. We would appreciate feedback *from everyone in the community* on the points where a decision hasn't been made below. gem5 is a community-driven project, and we need feedback to make sure we're making community-focused decisions. We will be introducing a new "stable" branch type to gem5. We are doing this for the following reasons: - Provide a way for developers to communicate major changes to the code. We will be providing detailed release notes for each stable release. - Increase our test coverage. At each stable release, we will test a large number of "common" benchmarks and configurations and publicize the current state of gem5. - Provide a way for researchers to communicate to the rest of the community information about their simulation infrastructure (e.g., in a paper you can say which version of gem5 you used). On the stable version of gem5, we will provide bugfixes until the next release, but we will not make any API changes or add new features. We would like your feedback on the following two questions: **Which branch should be default?** We can either have the master branch in git be the "stable" or the "development" branch. If master is the stable branch, then it's easier for users to get the most recent stable branch. If master is the development branch, it's more familiar and easier for most developers. Either way, we will be updating all of the documentation to make it clear. Please let us know which you prefer by replying "I think master should be stable" or "I think master should be development". **How often should we create a new gem5 release?** We can have a gem5 release once per year (likely in April) or three times per year (April, August, and December). Once per year means that if you use the stable branch you will get updates less frequently. Three times per year will mean there are more releases to choose from (but a newer release should always be better). On the development side, I don't think one will be more work than the other. Once per year means more backporting, and three times per year means more testing and time spent on releases. Please let us know which you prefer by replying "I think gem5 should be released once per year" or "I think gem5 should be released three times per year." A couple of notes to everyone who's been following the discussion on the gem5-dev mailing list: - We have dropped the proposal for major vs minor releases. Note that there was some pushback on having only major releases when this was proposed on the gem5 roadmap, but it sounded like the consensus was to drop minor releases for now. - We will still allow feature branches *in rare circumstances*. This will be by request only (send mail to gem5-dev if you would like to discuss adding a new branch), and the goal will be integration within a few months. All code review will still happen in the open on gerrit. The benefits will be 1) rebases won't be required as you can just make changes to the head of the branch 2) many features take more than a few months to implement, so if it's not ready by a release it can be pushed to the next 3) large changes won't be hidden in AMD or Arm-specific repositories and *anyone* will be able to request a branch. Thanks everyone for the discussions so far! It would be most useful to hear back by the end of the week. However, I don't expect any concrete actions will be taken until after the holidays. Cheers, Jason ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] [gem5-dev] gem5 stable release proposal [PLEASE VOTE!]
Hello Jason, Thanks for such a nice and detailed explanation. My votes are as follows: *I think master should be development* *I think gem5 should be released once per year* Best regards, Abhishek On Mon, Dec 16, 2019 at 2:50 PM Jason Lowe-Power wrote: > Hi all, > > As many of you have seen on gem5-dev, we are going to be adding a > "stable" version of gem5. Below is the current proposal. There are a > couple of points below where there has not been general consensus > reached. We would appreciate feedback *from everyone in the community* > on the points where a decision hasn't been made below. gem5 is a > community-driven project, and we need feedback to make sure we're > making community-focused decisions. > > We will be introducing a new "stable" branch type to gem5. We are > doing this for the following reasons: > - Provide a way for developers to communicate major changes to the > code. We will be providing detailed release notes for each stable > release. > - Increase our test coverage. At each stable release, we will test a > large number of "common" benchmarks and configurations and publicize > the current state of gem5. > - Provide a way for researchers to communicate to the rest of the > community information about their simulation infrastructure (e.g., in > a paper you can say which version of gem5 you used). > > On the stable version of gem5, we will provide bugfixes until the > next release, but we will not make any API changes or add new > features. > > We would like your feedback on the following two questions: > > **Which branch should be default?** > > We can either have the master branch in git be the "stable" or the > "development" branch. If master is the stable branch, then it's easier > for users to get the most recent stable branch. If master is the > development branch, it's more familiar and easier for most developers. > Either way, we will be updating all of the documentation to make it > clear. > > Please let us know which you prefer by replying "I think master should > be stable" or "I think master should be development". > > **How often should we create a new gem5 release?** > > We can have a gem5 release once per year (likely in April) or three > times per year (April, August, and December). Once per year means that > if you use the stable branch you will get updates less frequently. > Three times per year will mean there are more releases to choose from > (but a newer release should always be better). On the development > side, I don't think one will be more work than the other. Once per > year means more backporting, and three times per year means more > testing and time spent on releases. > > Please let us know which you prefer by replying "I think gem5 should > be released once per year" or "I think gem5 should be released three > times per year." > > > > > A couple of notes to everyone who's been following the discussion on > the gem5-dev mailing list: > - We have dropped the proposal for major vs minor releases. Note that > there was some pushback on having only major releases when this was > proposed on the gem5 roadmap, but it sounded like the consensus was to > drop minor releases for now. > - We will still allow feature branches *in rare circumstances*. This > will be by request only (send mail to gem5-dev if you would like to > discuss adding a new branch), and the goal will be integration within > a few months. All code review will still happen in the open on gerrit. > The benefits will be > 1) rebases won't be required as you can just make changes to the head > of the branch > 2) many features take more than a few months to implement, so if it's > not ready by a release it can be pushed to the next > 3) large changes won't be hidden in AMD or Arm-specific repositories > and *anyone* will be able to request a branch. > > Thanks everyone for the discussions so far! It would be most useful to > hear back by the end of the week. However, I don't expect any concrete > actions will be taken until after the holidays. > > Cheers, > Jason > ___ > gem5-dev mailing list > gem5-...@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] [gem5-dev] gem5 stable release proposal [PLEASE VOTE!]
- "I think master should be stable" - "I think gem5 should be released three times per year." Matt On Mon, Dec 16, 2019 at 1:57 PM Abhishek Singh < abhishek.singh199...@gmail.com> wrote: > Hello Jason, > Thanks for such a nice and detailed explanation. > My votes are as follows: > > > *I think master should be development* > > > *I think gem5 should be released once per year* > > > Best regards, > > Abhishek > > > On Mon, Dec 16, 2019 at 2:50 PM Jason Lowe-Power > wrote: > > > Hi all, > > > > As many of you have seen on gem5-dev, we are going to be adding a > > "stable" version of gem5. Below is the current proposal. There are a > > couple of points below where there has not been general consensus > > reached. We would appreciate feedback *from everyone in the community* > > on the points where a decision hasn't been made below. gem5 is a > > community-driven project, and we need feedback to make sure we're > > making community-focused decisions. > > > > We will be introducing a new "stable" branch type to gem5. We are > > doing this for the following reasons: > > - Provide a way for developers to communicate major changes to the > > code. We will be providing detailed release notes for each stable > > release. > > - Increase our test coverage. At each stable release, we will test a > > large number of "common" benchmarks and configurations and publicize > > the current state of gem5. > > - Provide a way for researchers to communicate to the rest of the > > community information about their simulation infrastructure (e.g., in > > a paper you can say which version of gem5 you used). > > > > On the stable version of gem5, we will provide bugfixes until the > > next release, but we will not make any API changes or add new > > features. > > > > We would like your feedback on the following two questions: > > > > **Which branch should be default?** > > > > We can either have the master branch in git be the "stable" or the > > "development" branch. If master is the stable branch, then it's easier > > for users to get the most recent stable branch. If master is the > > development branch, it's more familiar and easier for most developers. > > Either way, we will be updating all of the documentation to make it > > clear. > > > > Please let us know which you prefer by replying "I think master should > > be stable" or "I think master should be development". > > > > **How often should we create a new gem5 release?** > > > > We can have a gem5 release once per year (likely in April) or three > > times per year (April, August, and December). Once per year means that > > if you use the stable branch you will get updates less frequently. > > Three times per year will mean there are more releases to choose from > > (but a newer release should always be better). On the development > > side, I don't think one will be more work than the other. Once per > > year means more backporting, and three times per year means more > > testing and time spent on releases. > > > > Please let us know which you prefer by replying "I think gem5 should > > be released once per year" or "I think gem5 should be released three > > times per year." > > > > > > > > > > A couple of notes to everyone who's been following the discussion on > > the gem5-dev mailing list: > > - We have dropped the proposal for major vs minor releases. Note that > > there was some pushback on having only major releases when this was > > proposed on the gem5 roadmap, but it sounded like the consensus was to > > drop minor releases for now. > > - We will still allow feature branches *in rare circumstances*. This > > will be by request only (send mail to gem5-dev if you would like to > > discuss adding a new branch), and the goal will be integration within > > a few months. All code review will still happen in the open on gerrit. > > The benefits will be > > 1) rebases won't be required as you can just make changes to the head > > of the branch > > 2) many features take more than a few months to implement, so if it's > > not ready by a release it can be pushed to the next > > 3) large changes won't be hidden in AMD or Arm-specific repositories > > and *anyone* will be able to request a branch. > > > > Thanks everyone for the discussions so far! It would be most useful to > > hear back by the end of the week. However, I don't expect any concrete > > actions will be taken until after the holidays. > > > > Cheers, > > Jason > > ___ > > gem5-dev mailing list > > gem5-...@gem5.org > > http://m5sim.org/mailman/listinfo/gem5-dev > ___ > gem5-dev mailing list > gem5-...@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] gem5 stable release proposal [PLEASE VOTE!]
Hi Jason, Thanks for the proposal. Regarding the branch option for stable release, can we do it by git tagging? I think one-release per year is too long. I prefer three-release per year. Thanks, -Tao On Mon, Dec 16, 2019 at 11:50 AM Jason Lowe-Power wrote: > Hi all, > > As many of you have seen on gem5-dev, we are going to be adding a > "stable" version of gem5. Below is the current proposal. There are a > couple of points below where there has not been general consensus > reached. We would appreciate feedback *from everyone in the community* > on the points where a decision hasn't been made below. gem5 is a > community-driven project, and we need feedback to make sure we're > making community-focused decisions. > > We will be introducing a new "stable" branch type to gem5. We are > doing this for the following reasons: > - Provide a way for developers to communicate major changes to the > code. We will be providing detailed release notes for each stable > release. > - Increase our test coverage. At each stable release, we will test a > large number of "common" benchmarks and configurations and publicize > the current state of gem5. > - Provide a way for researchers to communicate to the rest of the > community information about their simulation infrastructure (e.g., in > a paper you can say which version of gem5 you used). > > On the stable version of gem5, we will provide bugfixes until the > next release, but we will not make any API changes or add new > features. > > We would like your feedback on the following two questions: > > **Which branch should be default?** > > We can either have the master branch in git be the "stable" or the > "development" branch. If master is the stable branch, then it's easier > for users to get the most recent stable branch. If master is the > development branch, it's more familiar and easier for most developers. > Either way, we will be updating all of the documentation to make it > clear. > > Please let us know which you prefer by replying "I think master should > be stable" or "I think master should be development". > > **How often should we create a new gem5 release?** > > We can have a gem5 release once per year (likely in April) or three > times per year (April, August, and December). Once per year means that > if you use the stable branch you will get updates less frequently. > Three times per year will mean there are more releases to choose from > (but a newer release should always be better). On the development > side, I don't think one will be more work than the other. Once per > year means more backporting, and three times per year means more > testing and time spent on releases. > > Please let us know which you prefer by replying "I think gem5 should > be released once per year" or "I think gem5 should be released three > times per year." > > > > > A couple of notes to everyone who's been following the discussion on > the gem5-dev mailing list: > - We have dropped the proposal for major vs minor releases. Note that > there was some pushback on having only major releases when this was > proposed on the gem5 roadmap, but it sounded like the consensus was to > drop minor releases for now. > - We will still allow feature branches *in rare circumstances*. This > will be by request only (send mail to gem5-dev if you would like to > discuss adding a new branch), and the goal will be integration within > a few months. All code review will still happen in the open on gerrit. > The benefits will be > 1) rebases won't be required as you can just make changes to the head > of the branch > 2) many features take more than a few months to implement, so if it's > not ready by a release it can be pushed to the next > 3) large changes won't be hidden in AMD or Arm-specific repositories > and *anyone* will be able to request a branch. > > Thanks everyone for the discussions so far! It would be most useful to > hear back by the end of the week. However, I don't expect any concrete > actions will be taken until after the holidays. > > Cheers, > Jason > ___ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] gem5 stable release proposal [PLEASE VOTE!]
Hi Jason, "I think master should be stable"as common case should be to use gem5 and not to dev it. "I think gem5 should be released three times per year." as I assume there would be too much to digest after one year. Best, On Mon, Dec 16, 2019 at 12:21 PM Tao Zhang wrote: > Hi Jason, > > Thanks for the proposal. > > Regarding the branch option for stable release, can we do it by git > tagging? > > I think one-release per year is too long. I prefer three-release per year. > > Thanks, > > -Tao > > > On Mon, Dec 16, 2019 at 11:50 AM Jason Lowe-Power > wrote: > >> Hi all, >> >> As many of you have seen on gem5-dev, we are going to be adding a >> "stable" version of gem5. Below is the current proposal. There are a >> couple of points below where there has not been general consensus >> reached. We would appreciate feedback *from everyone in the community* >> on the points where a decision hasn't been made below. gem5 is a >> community-driven project, and we need feedback to make sure we're >> making community-focused decisions. >> >> We will be introducing a new "stable" branch type to gem5. We are >> doing this for the following reasons: >> - Provide a way for developers to communicate major changes to the >> code. We will be providing detailed release notes for each stable >> release. >> - Increase our test coverage. At each stable release, we will test a >> large number of "common" benchmarks and configurations and publicize >> the current state of gem5. >> - Provide a way for researchers to communicate to the rest of the >> community information about their simulation infrastructure (e.g., in >> a paper you can say which version of gem5 you used). >> >> On the stable version of gem5, we will provide bugfixes until the >> next release, but we will not make any API changes or add new >> features. >> >> We would like your feedback on the following two questions: >> >> **Which branch should be default?** >> >> We can either have the master branch in git be the "stable" or the >> "development" branch. If master is the stable branch, then it's easier >> for users to get the most recent stable branch. If master is the >> development branch, it's more familiar and easier for most developers. >> Either way, we will be updating all of the documentation to make it >> clear. >> >> Please let us know which you prefer by replying "I think master should >> be stable" or "I think master should be development". >> >> **How often should we create a new gem5 release?** >> >> We can have a gem5 release once per year (likely in April) or three >> times per year (April, August, and December). Once per year means that >> if you use the stable branch you will get updates less frequently. >> Three times per year will mean there are more releases to choose from >> (but a newer release should always be better). On the development >> side, I don't think one will be more work than the other. Once per >> year means more backporting, and three times per year means more >> testing and time spent on releases. >> >> Please let us know which you prefer by replying "I think gem5 should >> be released once per year" or "I think gem5 should be released three >> times per year." >> >> >> >> >> A couple of notes to everyone who's been following the discussion on >> the gem5-dev mailing list: >> - We have dropped the proposal for major vs minor releases. Note that >> there was some pushback on having only major releases when this was >> proposed on the gem5 roadmap, but it sounded like the consensus was to >> drop minor releases for now. >> - We will still allow feature branches *in rare circumstances*. This >> will be by request only (send mail to gem5-dev if you would like to >> discuss adding a new branch), and the goal will be integration within >> a few months. All code review will still happen in the open on gerrit. >> The benefits will be >> 1) rebases won't be required as you can just make changes to the head >> of the branch >> 2) many features take more than a few months to implement, so if it's >> not ready by a release it can be pushed to the next >> 3) large changes won't be hidden in AMD or Arm-specific repositories >> and *anyone* will be able to request a branch. >> >> Thanks everyone for the discussions so far! It would be most useful to >> hear back by the end of the week. However, I don't expect any concrete >> actions will be taken until after the holidays. >> >> Cheers, >> Jason >> ___ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users > > ___ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users -- Pouya Fotouhi PhD Candidate Department of Electrical and Computer Engineering University of California, Davis ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailm
Re: [gem5-users] [gem5-dev] gem5 stable release proposal [PLEASE VOTE!]
* I think master should be stable * I think gem5 should be released three times per year -- Dr. Bobby R. Bruce Room 2235, Kemper Hall, UC Davis Davis, CA, 95616 On Mon, Dec 16, 2019 at 11:50 AM Jason Lowe-Power wrote: > Hi all, > > As many of you have seen on gem5-dev, we are going to be adding a > "stable" version of gem5. Below is the current proposal. There are a > couple of points below where there has not been general consensus > reached. We would appreciate feedback *from everyone in the community* > on the points where a decision hasn't been made below. gem5 is a > community-driven project, and we need feedback to make sure we're > making community-focused decisions. > > We will be introducing a new "stable" branch type to gem5. We are > doing this for the following reasons: > - Provide a way for developers to communicate major changes to the > code. We will be providing detailed release notes for each stable > release. > - Increase our test coverage. At each stable release, we will test a > large number of "common" benchmarks and configurations and publicize > the current state of gem5. > - Provide a way for researchers to communicate to the rest of the > community information about their simulation infrastructure (e.g., in > a paper you can say which version of gem5 you used). > > On the stable version of gem5, we will provide bugfixes until the > next release, but we will not make any API changes or add new > features. > > We would like your feedback on the following two questions: > > **Which branch should be default?** > > We can either have the master branch in git be the "stable" or the > "development" branch. If master is the stable branch, then it's easier > for users to get the most recent stable branch. If master is the > development branch, it's more familiar and easier for most developers. > Either way, we will be updating all of the documentation to make it > clear. > > Please let us know which you prefer by replying "I think master should > be stable" or "I think master should be development". > > **How often should we create a new gem5 release?** > > We can have a gem5 release once per year (likely in April) or three > times per year (April, August, and December). Once per year means that > if you use the stable branch you will get updates less frequently. > Three times per year will mean there are more releases to choose from > (but a newer release should always be better). On the development > side, I don't think one will be more work than the other. Once per > year means more backporting, and three times per year means more > testing and time spent on releases. > > Please let us know which you prefer by replying "I think gem5 should > be released once per year" or "I think gem5 should be released three > times per year." > > > > > A couple of notes to everyone who's been following the discussion on > the gem5-dev mailing list: > - We have dropped the proposal for major vs minor releases. Note that > there was some pushback on having only major releases when this was > proposed on the gem5 roadmap, but it sounded like the consensus was to > drop minor releases for now. > - We will still allow feature branches *in rare circumstances*. This > will be by request only (send mail to gem5-dev if you would like to > discuss adding a new branch), and the goal will be integration within > a few months. All code review will still happen in the open on gerrit. > The benefits will be > 1) rebases won't be required as you can just make changes to the head > of the branch > 2) many features take more than a few months to implement, so if it's > not ready by a release it can be pushed to the next > 3) large changes won't be hidden in AMD or Arm-specific repositories > and *anyone* will be able to request a branch. > > Thanks everyone for the discussions so far! It would be most useful to > hear back by the end of the week. However, I don't expect any concrete > actions will be taken until after the holidays. > > Cheers, > Jason > ___ > gem5-dev mailing list > gem5-...@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
Re: [gem5-users] [gem5-dev] gem5 stable release proposal [PLEASE VOTE!]
- I think master should be stable - I think gem5 should be released three times per year Regards,Daniel Em segunda-feira, 16 de dezembro de 2019 22:33:14 GMT+1, Bobby Bruce escreveu: * I think master should be stable * I think gem5 should be released three times per year -- Dr. Bobby R. Bruce Room 2235, Kemper Hall, UC Davis Davis, CA, 95616 On Mon, Dec 16, 2019 at 11:50 AM Jason Lowe-Power wrote: > Hi all, > > As many of you have seen on gem5-dev, we are going to be adding a > "stable" version of gem5. Below is the current proposal. There are a > couple of points below where there has not been general consensus > reached. We would appreciate feedback *from everyone in the community* > on the points where a decision hasn't been made below. gem5 is a > community-driven project, and we need feedback to make sure we're > making community-focused decisions. > > We will be introducing a new "stable" branch type to gem5. We are > doing this for the following reasons: > - Provide a way for developers to communicate major changes to the > code. We will be providing detailed release notes for each stable > release. > - Increase our test coverage. At each stable release, we will test a > large number of "common" benchmarks and configurations and publicize > the current state of gem5. > - Provide a way for researchers to communicate to the rest of the > community information about their simulation infrastructure (e.g., in > a paper you can say which version of gem5 you used). > > On the stable version of gem5, we will provide bugfixes until the > next release, but we will not make any API changes or add new > features. > > We would like your feedback on the following two questions: > > **Which branch should be default?** > > We can either have the master branch in git be the "stable" or the > "development" branch. If master is the stable branch, then it's easier > for users to get the most recent stable branch. If master is the > development branch, it's more familiar and easier for most developers. > Either way, we will be updating all of the documentation to make it > clear. > > Please let us know which you prefer by replying "I think master should > be stable" or "I think master should be development". > > **How often should we create a new gem5 release?** > > We can have a gem5 release once per year (likely in April) or three > times per year (April, August, and December). Once per year means that > if you use the stable branch you will get updates less frequently. > Three times per year will mean there are more releases to choose from > (but a newer release should always be better). On the development > side, I don't think one will be more work than the other. Once per > year means more backporting, and three times per year means more > testing and time spent on releases. > > Please let us know which you prefer by replying "I think gem5 should > be released once per year" or "I think gem5 should be released three > times per year." > > > > > A couple of notes to everyone who's been following the discussion on > the gem5-dev mailing list: > - We have dropped the proposal for major vs minor releases. Note that > there was some pushback on having only major releases when this was > proposed on the gem5 roadmap, but it sounded like the consensus was to > drop minor releases for now. > - We will still allow feature branches *in rare circumstances*. This > will be by request only (send mail to gem5-dev if you would like to > discuss adding a new branch), and the goal will be integration within > a few months. All code review will still happen in the open on gerrit. > The benefits will be > 1) rebases won't be required as you can just make changes to the head > of the branch > 2) many features take more than a few months to implement, so if it's > not ready by a release it can be pushed to the next > 3) large changes won't be hidden in AMD or Arm-specific repositories > and *anyone* will be able to request a branch. > > Thanks everyone for the discussions so far! It would be most useful to > hear back by the end of the week. However, I don't expect any concrete > actions will be taken until after the holidays. > > Cheers, > Jason > ___ > gem5-dev mailing list > gem5-...@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-dev mailing list gem5-...@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev ___ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
