Commit Graph

7 Commits

Author SHA1 Message Date
36ae6fd6c3 prune-trace: use none/none only without any parameters
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
2014-02-25 13:32:55 +01:00
4cb97a7fa5 formatting, typos, comments, details
Change-Id: Iae5f1acb653a694622e9ac2bad93efcfca588f3a
2014-01-22 13:08:13 +01:00
56bfa6c693 tools/prune-trace: various improvements
- 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
2013-04-22 14:24:50 +02:00
0f16f18d75 cosmetics
Change-Id: Ifae805ae1e2dac95324e054af09a7b70f5d5b60c
2013-04-22 14:24:02 +02:00
c24ed774b0 experiments/dciao-kernelstructs: new database driven experiment for DCiAO
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
2013-04-03 10:39:51 +02:00
f18cddc63c DatabaseCampaign: abstract campain for interaction with MySQL Database
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
2013-04-02 09:52:42 +02:00
3a5dc285ab tools/prune-trace: fault-space pruning tool
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
2013-03-26 16:19:05 +01:00