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

Support per-process frequency #57

Open
wentasah opened this issue Jul 19, 2021 · 4 comments
Open

Support per-process frequency #57

wentasah opened this issue Jul 19, 2021 · 4 comments
Assignees

Comments

@wentasah
Copy link
Member

The frequency will be configured in the configuration file with the frequency key. The value will be in MHz. For example:

partitions:
  - name: BE1
    processes:
      - cmd: ./best_effort_application1
        budget: 200
        frequency: 1200

Processes without the specified frequency should run with the frequency specified by the global PM policy, i.e. the -p switch. If no policy (-p) is specified on the command line, DEmOS should fail (with reasonable error message), when it encounters configuration with per-process frequency.

If the user specifies unfeasible frequencies, e.g. two partitions running on the same i.MX8 CPU cluster, an error will be reported prior to runtime. There is no need to check whether the per-process frequency conflicts with frequencies (even the default ones) on other partitions running on the same cluster. Just fail if multiple partitions are running on the same cluster and at least one specifies arbitrary per-process frequency.

This should be primarily supported for best-effort partitions, but it might be useful if this is also supported for safety-critical partitions (I can image some experiments, where it would be useful). When the per-process frequency will be specified for an SC process, DEmOS should emit an warning (at the beginning), but should continue running the workload.

@MatejKafka
Copy link
Collaborator

MatejKafka commented Jul 19, 2021

  1. Is it ok to only support imx8?
  2. What to do for a process that is switched between A53 and A72 cluster in different windows? It would imo make more sense to specify both A53 and A72 frequencies (possibly only as an index between 0 and 3, which is easier to remember when writing the configuration file), and use one or both depending on the cluster the process is currently running on
  3. my current implementation uses a separate power policy for this, so that if -p imx8_per_process is passed, the frequencies from the config file are used, with a fixed default for the other processes, and otherwise they are ignored; is it a requirement to set both a global power policy and a per-process frequency, or is it OK to only set one at a time?

@wentasah
Copy link
Member Author

  1. Yes
  2. Fail with message that it is currently unsupported. It's also OK to fail the same way if the partition with per-process frequency specification is scheduled in more than one window.
    2a. I don't want to have frequency indexes in the configuration file - it could easily lead to various errors like I specify "3" and I mean 1200 MHz, but because I run it by mistake on A72, it would run on different frequency and do not notice.
  3. It's OK to use a special power policy for this.

@MatejKafka
Copy link
Collaborator

2a. Even with frequencies, you could set 600 MHz (which is supported by both A53 and A72) and apply it to the wrong cluster.

@wentasah
Copy link
Member Author

Yes, but it will run at 600 MHz and not at some random unexpected frequency.

MatejKafka added a commit that referenced this issue Sep 9, 2021
…to runtime checks in PowerPolicy

The checks here are more benevolent, only reporting an actual collision rather than all potential ones. However, if there's a race condition, the runtime checks may not always catch it.

TODO: if a collision is detected, it throws a runtime exception, which stops the scheduler without a cleanup, leaving behind processes and cgroups
MatejKafka added a commit that referenced this issue Sep 9, 2021
…to runtime checks in PowerPolicy

The checks here are more benevolent, only reporting an actual collision rather than all potential ones. However, if there's a race condition, the runtime checks may not always catch it.

TODO: if a collision is detected, it throws a runtime exception, which stops the scheduler without a cleanup, leaving behind processes and cgroups
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

No branches or pull requests

2 participants