Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RTA: Add support for barrier workloads #461

Closed
wants to merge 2 commits into from

Conversation

bjackman
Copy link
Contributor

@bjackman bjackman commented Aug 8, 2017

Allows a synthetic which runs a set amount of time and then waits on a barrier. To be used for an extension of the heavy_load test that can simulate certain benchmarks.

Brendan Jackman added 2 commits August 8, 2017 19:41
This type of task translates to an rt-app phase containing a 'run' event and a
'barrier' event, the name of the barrier being provided as a constructor
argument.

Implementing this requires some internal changes to the rta module:

- The Phase class gains a barrier_after attribute. Since this is optional, the
  class now inherits from object instead of using a namedtuple.

- The Phase objects' 'period_ms' field can now be None - it is now only accessed
  where it is required.

- The task_phase object constructed in _confProfile, which now contains a
  'barrier' field, is now order-sensitive, i.e. the 'barrier' field must come
  after the 'run' field. To preserve this ordering, we need to remove the
  'sort_keys=True' from the json.dump call, which in turn requires that the
  entire phases object by converted to an OrderedDict.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants