Implementation of core scheduling

[alessiomana]

Dear maintainers,
please find attached my tentative implementation of core scheduling in rt-app.
This project is part of my master thesis which I developed under the supervision of prof. Enrico Bini, at University of Turin.
We previously contacted Juri Lelli who recommended us to submit this pull request.
We look forward for your comments and we are happy to modify our code as needed.
Best regards,
Alessio Mana
Enrico Bini

[jlelli]

Hi @alessiomana,

Had a very quick pass at your work, thanks for implementing this feature!

However, I have the feeling that a better/cleaner organization and presentation of the changes will make the review process better.

Could you please clean up the series by, for example, removing intermediate debug/fix commits and consolidate the changes in less commits? Ideally every commit should make sense in itself (i.e. it introduces a basic building block or a feature or maybe documentation and/or examples).

Thanks!

[vingu-linaro]

+1 for squashing the series in a smaller number of patches. This will help to review and comment

Few comments:

• Could you make "core_scheduling_families_count" optional and count the number of sched core cookie while parsing the config ? All the resources are dynamically allocated when parsing the json file
• Have you managed the case where the core_scheduling_first_threads exits before the end of the use case and another thread needs to set a cookie after the former exits ? I think this can happen with fork events
• don't know if that make sense but should we be able to change sched core cookie during a phase ? like taskgroup , cpuset and scheduling policy ?

Besides the comments above, I have successfully tested your branch on my dev board

[alessiomana]

+1 for squashing the series in a smaller number of patches. This will help to review and comment

We are working on it. You may see intermediate commits, please ignore them until we will be done.

Few comments:

• Could you make "core_scheduling_families_count" optional and count the number of sched core cookie while parsing the config ? All the resources are dynamically allocated when parsing the json file

Yes, will do.

• Have you managed the case where the core_scheduling_first_threads exits before the end of the use case and another thread needs to set a cookie after the former exits ? I think this can happen with fork events
• don't know if that make sense but should we be able to change sched core cookie during a phase ? like taskgroup , cpuset and scheduling policy ?

To address these comments, we are considering two different implementations:

1. To create a dummy thread per family. Such a thread would always be sleeping and is used only to copy its core scheduling cookie to the core scheduled threads, or
2. To create and maintain a list of pids belonging to the same family.

We prefer the first option as it allows simpler implementation of the per-phase scheduling. Still we welcome very much any suggestion.