Difference between revisions of "Configuration musings"
(Created page with "===Background=== The configurations we have work, but are really hard to learn and the code is getting harder and harder to effectively maintain ===Issues=== A extensible co...") |
(No difference)
|
Revision as of 12:17, 29 June 2012
Background
The configurations we have work, but are really hard to learn and the code is getting harder and harder to effectively maintain
Issues
A extensible configuration system is one of the road blocks to a better regression system Asymmetric configurations are problematic with the current system as we need to come up with a way to set CPUID information for each cluster and size them independently Having clocks to emulate some sort of DVFS (just frequency scaling) is hard. Ultimately you'd like to be able to change the clock and associated objects (caches etc) would all slow down or speed up.
Possible Solutions
There are a couple of things that I propose here, but generally it involves creating a CPU container object (or maybe more generally a container object). The container has a set of ports so that functions can always know how to connect to them, but it's not a specific object. In this way we could wrap a core + l1s in a container and hand it to another function to build a cluster out of and similar we could hand multiple containers of objects to a system to build a multi-cluster system. The containers could have clocks and in that way we could use the'Nc' notation for latencies in gem5 where instead of specifying '10ns' you can specify '5c' (5 of the parent clocks), so that should deal with the first level of configuration issues. Th
The second part of the process is to make the various building function we have much more generic in what they do and move them to be part of gem5. This is somewhat like what addL1caches() or connectAllPorts() does on CPU models, but we should have more them and they should take objects to instantiate, not instantiate fixed object. Another part of it is better use of Base classes. If we name all L1 caches L1Cache (maybe BL1Cache/LL1Cache for an asymmetric system), then a script to change all the big or the little cache sizes is as stipple as BL1Cache = '32kB', no crazy tree of if statements is required.
Finally, it might let use use decorators to build a system, for example if we start with a working configuration we could then have decorators (http://stackoverflow.com/questions/739654/understanding-python-decorators) permute it:
@detailedCPU(A15Like)
@L1caches('64kb')
@L2caches('2MB')
@makeMultiCluster(2)
makeArmSystem(cores=4)
With the underlying containers the decorators should be able to pull apart and recreate the system each time adding the functionality.
