Commit b5c828d5 authored by Philip Carns's avatar Philip Carns

add rough readme and todo files

parent 8821caef
The codes-workload component provides a standardized mechanism to describe
I/O workloads to be executed in a storage simulation.
codes/codes-workload.h
----------------------
This is the API that storage simulations will use to retrieve I/O
operations to execute within the simulation. The primary functions are:
- codes_workload_load(): loads the specified workload instance
- codes_workload_get_next(): retrieves the next I/O operation for a given
rank
- codes_workload_get_next_rc(): reverse version of the above
The operations are described by the codes_workload_op struct. The end of
the stream of operations for a given rank is indicated by the CODES_WK_END
operation.
src/workload/codes-workload.c:
---------------------
Implementation of the codes/codes-workload.h API.
src/workload/codes-workload-method.h:
---------------------
This is the API to be implemented by specific workload generator methods
(a generator that produces operations based on a Darshan log, for example).
Multiple workload generator methods can be used by the same simulation as
long as they support the same interface. This API is similar to the
top-level codes/codes-workload.h API, except that there is no reverse
computation function. Workload generators do not need to handle that case.
src/workload/test-workload-method.c:
---------------------
This is an example workload generator that implements the
codes-workload-method.h interface. It produces a static workload for
testing purposes.
test program (tests/workload/*):
---------------------
codes-workload-test.c: main routine for a simulator that provides an example
of 48 clients executing a workload described by the test-workload-method on
16 servers. Can be executed as follows:
(parallel, optimistic example)
mpiexec -n 16 tests/workload/codes-workload-test --sync=3
(serial, conservative example)
tests/workload/codes-workload-test --sync=1
The test code is split up so that the compute node LPs are implemented in
codes-workload-test-cn-lp.* and the server LPs are implemented in
codes-workload-test-svr-lp.*. Note that the timing information is
completely arbitrary for testing purposes; this is not a true storage
simulator but just a test harness.
The compute node LP implements its own barrier and delay operations. Other
operations are sent to the server LPs for execution.
- Generalize the notation used to identify entities in the application (they
are referred to by ranks right now). See email from Dries 9/18/2013.
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment