This change moves prune-trace's --variants-exclude / --benchmarks-exclude
capabilities to Database::get_variants() to make it available to all users.
Change-Id: Icbc6bb1a3ae7c846d2de40b881f47a9cc1ed7bbf
In some cases the write-pilot is located at the upper boundary of the
experiment and thus is in a race situation with the experiment's end.
If the experiment's end occurs first, the campaign ends and complains
about missing data, otherwise everything is fine.
This patch circumvents this via using "the first" writing pilot; iff the
only write is located at the experiment's end, the race will still occur,
but cleverly written experiment code can, according to hsc, circumvent it.
Change-Id: I6a27a8c4770c04ea8dcaef8aa7bd85d18f43f0b5
During the prune step the data_width of the injected location was not
propagated before. It is now stored in fsppilot (database layout change!) and
sent in the fsppilot protobuf message.
Change-Id: I0562f6fc8957adea0f8a9fb63469ca5e3f4b7b2d
Is now very similar to normal importer, and may be deleted in the future, but
at the moment, this should be merged, since it is the importer used in the
sobres-2013 paper.
This changes the MySQL Schema. instr1_absolute was introduced.
Change-Id: I1bc2919bd14c335beca6d586b7cc0f80767ad7d5
- 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
