Searched hist:7861 (Results 1 - 6 of 6) sorted by relevance
| /gem5/util/maint/ | ||
| H A D | show_changes_by_file.py | 12893:3813d345cbac Mon Feb 05 13:15:00 EST 2018 Brandon Potter <brandon.potter@amd.com> util: add util/maint/show_changes_by_file.py tool The script diffs an upstream branch and a feature branch to find all files which have been changed between the branches. It then searches for all the corresponding changesets and binds them to the files in the output. The tool's output resembles the following: /path/to/file/ filename git-hash git-hash filename git-hash /path/to/file/ filename git-hash Change-Id: Icd67953748f38dad984488c5445313eaa56fa202 Reviewed-on: https://gem5-review.googlesource.com/7861 Reviewed-by: Brandon Potter <Brandon.Potter@amd.com> Maintainer: Brandon Potter <Brandon.Potter@amd.com> |
| /gem5/src/sim/ | ||
| H A D | Root.py | 7861:4ebff121cc0e Wed Jan 19 14:48:00 EST 2011 Gabe Black <gblack@eecs.umich.edu> Time: Add a mechanism to prevent M5 from running faster than real time. M5 skips over any simulated time where it doesn't have any work to do. When the simulation is active, the time skipped is short and the work done at any point in time is relatively substantial. If the time between events is long and/or the work to do at each event is small, it's possible for simulated time to pass faster than real time. When running a benchmark that can be good because it means the simulation will finish sooner in real time. When interacting with the real world through, for instance, a serial terminal or bridge to a real network, this can be a problem. Human or network response time could be greatly exagerated from the perspective of the simulation and make simulated events happen "too soon" from an external perspective. This change adds the capability to force the simulation to run no faster than real time. It does so by scheduling a periodic event that checks to see if its simulated period is shorter than its real period. If it is, it stalls the simulation until they're equal. This is called time syncing. A future change could add pseudo instructions which turn time syncing on and off from within the simulation. That would allow time syncing to be used for the interactive parts of a session but then turned off when running a benchmark using the m5 utility program inside a script. Time syncing would probably not happen anyway while running a benchmark because there would be plenty of work for M5 to do, but the event overhead could be avoided. |
| H A D | root.hh | 7861:4ebff121cc0e Wed Jan 19 14:48:00 EST 2011 Gabe Black <gblack@eecs.umich.edu> Time: Add a mechanism to prevent M5 from running faster than real time. M5 skips over any simulated time where it doesn't have any work to do. When the simulation is active, the time skipped is short and the work done at any point in time is relatively substantial. If the time between events is long and/or the work to do at each event is small, it's possible for simulated time to pass faster than real time. When running a benchmark that can be good because it means the simulation will finish sooner in real time. When interacting with the real world through, for instance, a serial terminal or bridge to a real network, this can be a problem. Human or network response time could be greatly exagerated from the perspective of the simulation and make simulated events happen "too soon" from an external perspective. This change adds the capability to force the simulation to run no faster than real time. It does so by scheduling a periodic event that checks to see if its simulated period is shorter than its real period. If it is, it stalls the simulation until they're equal. This is called time syncing. A future change could add pseudo instructions which turn time syncing on and off from within the simulation. That would allow time syncing to be used for the interactive parts of a session but then turned off when running a benchmark using the m5 utility program inside a script. Time syncing would probably not happen anyway while running a benchmark because there would be plenty of work for M5 to do, but the event overhead could be avoided. |
| H A D | root.cc | 7861:4ebff121cc0e Wed Jan 19 14:48:00 EST 2011 Gabe Black <gblack@eecs.umich.edu> Time: Add a mechanism to prevent M5 from running faster than real time. M5 skips over any simulated time where it doesn't have any work to do. When the simulation is active, the time skipped is short and the work done at any point in time is relatively substantial. If the time between events is long and/or the work to do at each event is small, it's possible for simulated time to pass faster than real time. When running a benchmark that can be good because it means the simulation will finish sooner in real time. When interacting with the real world through, for instance, a serial terminal or bridge to a real network, this can be a problem. Human or network response time could be greatly exagerated from the perspective of the simulation and make simulated events happen "too soon" from an external perspective. This change adds the capability to force the simulation to run no faster than real time. It does so by scheduling a periodic event that checks to see if its simulated period is shorter than its real period. If it is, it stalls the simulation until they're equal. This is called time syncing. A future change could add pseudo instructions which turn time syncing on and off from within the simulation. That would allow time syncing to be used for the interactive parts of a session but then turned off when running a benchmark using the m5 utility program inside a script. Time syncing would probably not happen anyway while running a benchmark because there would be plenty of work for M5 to do, but the event overhead could be avoided. |
| H A D | SConscript | 7861:4ebff121cc0e Wed Jan 19 14:48:00 EST 2011 Gabe Black <gblack@eecs.umich.edu> Time: Add a mechanism to prevent M5 from running faster than real time. M5 skips over any simulated time where it doesn't have any work to do. When the simulation is active, the time skipped is short and the work done at any point in time is relatively substantial. If the time between events is long and/or the work to do at each event is small, it's possible for simulated time to pass faster than real time. When running a benchmark that can be good because it means the simulation will finish sooner in real time. When interacting with the real world through, for instance, a serial terminal or bridge to a real network, this can be a problem. Human or network response time could be greatly exagerated from the perspective of the simulation and make simulated events happen "too soon" from an external perspective. This change adds the capability to force the simulation to run no faster than real time. It does so by scheduling a periodic event that checks to see if its simulated period is shorter than its real period. If it is, it stalls the simulation until they're equal. This is called time syncing. A future change could add pseudo instructions which turn time syncing on and off from within the simulation. That would allow time syncing to be used for the interactive parts of a session but then turned off when running a benchmark using the m5 utility program inside a script. Time syncing would probably not happen anyway while running a benchmark because there would be plenty of work for M5 to do, but the event overhead could be avoided. |
| /gem5/configs/example/ | ||
| H A D | fs.py | 7861:4ebff121cc0e Wed Jan 19 14:48:00 EST 2011 Gabe Black <gblack@eecs.umich.edu> Time: Add a mechanism to prevent M5 from running faster than real time. M5 skips over any simulated time where it doesn't have any work to do. When the simulation is active, the time skipped is short and the work done at any point in time is relatively substantial. If the time between events is long and/or the work to do at each event is small, it's possible for simulated time to pass faster than real time. When running a benchmark that can be good because it means the simulation will finish sooner in real time. When interacting with the real world through, for instance, a serial terminal or bridge to a real network, this can be a problem. Human or network response time could be greatly exagerated from the perspective of the simulation and make simulated events happen "too soon" from an external perspective. This change adds the capability to force the simulation to run no faster than real time. It does so by scheduling a periodic event that checks to see if its simulated period is shorter than its real period. If it is, it stalls the simulation until they're equal. This is called time syncing. A future change could add pseudo instructions which turn time syncing on and off from within the simulation. That would allow time syncing to be used for the interactive parts of a session but then turned off when running a benchmark using the m5 utility program inside a script. Time syncing would probably not happen anyway while running a benchmark because there would be plenty of work for M5 to do, but the event overhead could be avoided. |
Completed in 61 milliseconds