If no --variant / --benchmark is specified, it's more reasonable to
prune or run *all* variants/benchmarks (using the wildcard "%")
instead of defaulting to "none"/"none". The trivial case with only
one single variant/benchmark (which may still be "none"/"none" if
import-trace's default is used) is still covered by this new default
behavior.
Change-Id: I0e9001137d5e052183dd74211e2edbcfab749528
The FESamplingPruner implements the fault-expansion variance reduction
technique (FE-VRT) as described in: Smith, D. Todd and Johnson, Barry W. and
Andrianos, Nikos and Profeta, III, Joseph A., "A variance-reduction technique
via fault-expansion for fault-coverage estimation" (1997), 366--374.
Change-Id: I04a0c9bb2622974278bd8c73793e51451119e650
Before this change, running prune-trace with, e.g.
"prune-trace -d fsp_mibench -v bitmap% --benchmark-exclude clockcnv"
resulted in an implied "--benchmark none", rendering --benchmark-exclude
ineffective and resulting in nothing being pruned. Now, the "none" default
only applies when neither --benchmark nor --benchmark-exclude (analogously
for --variant / --variant-exclude) is provided.
Change-Id: Ic7c88919d7cfde1261749a745dc6a679472ff348
- Variants/benchmarks can now be selected with wildcards
(--variant/--benchmark), and can be excluded from pruning
(--variant-exclude/--benchmark-exclude).
- The database clearing step can be skipped with --no-delete to
avoid deadlocks with concurrent DB accesses.
- Internals:
* injection_instr / injection_instr_absolute moves from
fspgroup to fsppilot. fsppilot now contains all information we
need for running FI experiments.
TODO: generic campaign needs to be modified, too.
* Force MySQL to use an efficient join order (STRAIGHT_JOIN).
Change-Id: I6241ea2de9da1a1e709fae6374df4fc06ef262a0
The dciao-kernelstructs experiment does a trace imported by the
DCiAOKernelImporter:
bin/import-trace -t trace.pb -i DCiAOKernelImporter --elf-file app.elf
Pruned by the basic method:
bin/prune-trace
and does CiAO fault injection experiments, where the results are
stored in the database.
Change-Id: I485dc2e5097b3ebaf354241f474ee3d317213707
The DatabaseCampaign interacts with the MySQL tables that are created
by the import-trace and prune-trace tools. It does offer all
unfinished experiment pilots from the database to the
fail-clients. Those clients send back a (by the experiment) defined
protobuf message as a result. The custom protobuf message does have to
need the form:
import "DatabaseCampaignMessage.proto";
message ExperimentMsg {
required DatabaseCampaignMessage fsppilot = 1;
repeated group Result = 2 {
// custom fields
required int32 bitoffset = 1;
optional int32 result = 2;
}
}
The DatabaseCampaignMessage is the pilot identifier from the
database. For each of the repeated result entries a row in a table is
allocated. The structure of this table is constructed (by protobuf
reflection) from the description of the message. Each field in the
Result group becomes a column in the result table. For the given
example it would be:
CREATE TABLE result_ExperimentMessage(
pilot_id INT,
bitoffset INT NOT NULL,
result INT,
PRIMARY_KEY(pilot_id)
)
Change-Id: I28fb5488e739d4098b823b42426c5760331027f8
This tool creates the fault-space pruning pilot and group
entries. Those are used by the generic campaign to do fault
experiments.
Currently prune-trace only implements conventional def/use pruning
(--prune-method "basic").
Change-Id: I1dfb431e3b1d3cd2ee891a49a3b6ac01210be11f
