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

Cyclic execution of BE processes in a long windows #68

Open
benedond opened this issue Nov 1, 2021 · 3 comments
Open

Cyclic execution of BE processes in a long windows #68

benedond opened this issue Nov 1, 2021 · 3 comments

Comments

@benedond
Copy link
Contributor

benedond commented Nov 1, 2021

I thought that BE processes are executed in a cyclic manner in such a way that if the last one is interrupted (out of budget) and there is still some time remaining within the window, the first one will continue again. But that does not seem to be the case.

Assume this configuration with two infinite processes - limited by a budget of 1 second executed within the 10-seconds long window. I thought that these processes should be repeated executed about 5 times each before the window finishes.

partitions:
  - name: be_a53
    processes:
      - {budget:  1000, frequency:  345.6, cmd: "yes > /dev/null"}
      - {budget:  1000, frequency:  499.2, cmd: "yes > /dev/null"}
windows:
  - length: 10000
    slices:
      - cpu: 0,3,4,5
        be_partition: be_a53

But the trace shows that after suspending the second process (13846), there is an 8-seconds long idle-time before the window starts for the second time.

>>> 13:07:13.809 [trace] Starting BE partitions
>>> 13:07:13.809 [trace] Running process '13845' for '1000 milliseconds'
>>> 13:07:13.809 [trace] Resuming process '13845' (partition 'be_a53')
>>> 13:07:13.809 [trace] Changing CPU frequency to '345.6 MHz' for 'policy0'
>>> 13:07:14.809 [trace] Suspended process '13845' (partition 'be_a53')
>>> 13:07:14.809 [trace] Running process '13846' for '1000 milliseconds'
>>> 13:07:14.810 [trace] Resuming process '13846' (partition 'be_a53')
>>> 13:07:14.810 [trace] Changing CPU frequency to '499.2 MHz' for 'policy0'
>>> 13:07:15.809 [trace] Suspended process '13846' (partition 'be_a53')     # <-- the second process suspended here
>>> 13:07:23.809 [trace] Starting window
>>> 13:07:23.809 [trace] Starting BE partitions
>>> 13:07:23.809 [trace] Running process '13845' for '1000 milliseconds'
>>> 13:07:23.809 [trace] Resuming process '13845' (partition 'be_a53')
>>> 13:07:23.809 [trace] Changing CPU frequency to '345.6 MHz' for 'policy0'
>>> 13:07:24.809 [trace] Suspended process '13845' (partition 'be_a53')
>>> 13:07:24.809 [trace] Running process '13846' for '1000 milliseconds'
>>> 13:07:24.809 [trace] Resuming process '13846' (partition 'be_a53')
>>> 13:07:24.810 [trace] Changing CPU frequency to '499.2 MHz' for 'policy0'
>>> 13:07:25.809 [trace] Suspended process '13846' (partition 'be_a53')
@MatejKafka
Copy link
Collaborator

Currently, BE processes are executed at most once. It shouldn't be too hard to cycle them instead, if it's necessary.

@wentasah
Copy link
Member

wentasah commented Nov 1, 2021

@MatejKafka can you try to implement it? At least a quick draft to see how many changes it would require?

MatejKafka added a commit that referenced this issue Nov 22, 2021
I don't like that this uses the internal Partition::clear_completed_flag method from Slice. I think that a more architecturally sound solution would be to create BePartition and ScPartition subclasses and move as much of the partition-related logic there, as the special cases for SC and BE are starting to pile up a bit inside Slice.
@MatejKafka
Copy link
Collaborator

@wentasah See the commit referencing this issue (above) for a quick mockup. This should be functional, but see the commit message.

MatejKafka added a commit that referenced this issue Nov 13, 2022
I don't like that this uses the internal Partition::clear_completed_flag method from Slice. I think that a more architecturally sound solution would be to create BePartition and ScPartition subclasses and move as much of the partition-related logic there, as the special cases for SC and BE are starting to pile up a bit inside Slice.
MatejKafka added a commit that referenced this issue Nov 14, 2022
I don't like that this uses the internal Partition::clear_completed_flag method from Slice. I think that a more architecturally sound solution would be to create BePartition and ScPartition subclasses and move as much of the partition-related logic there, as the special cases for SC and BE are starting to pile up a bit inside Slice.
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

3 participants