Difference between revisions of "Configuration musings"

Revision as of 12:26, 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.

Rethinking configuration from the ground up

1. fix the paths stuff 1. encapsulate the right things in SysConfig() 1. re-do the notion of benchmarks where a benchmark is a directory with a configuration file in it; search for necessary files in this directory or the search paths; don't need to edit a file to add the benchmarks just go looking for directories with benchmark.cfg or whatever in it 1. Create generic classes within gem5 for as many objects as possible (e.g. L1ICache, etc) 1. Create helper functions that live in gem5 such as connectAllPorts() to connect objects 1. When objects are being instantiated, pass those objects as kv parameters (with defaults) rather then hard coding their names so that someone can utilize the function 1. Remove as much duplication as possible with the above in FSConfig.py 1. Provide a mechanism to supply "default" configs that can execute a request of L1ICache.size = ... commands and make the topology look like a particular configuration 1. Re-write simulation.py to be comprehendible