Priorities

Topic

Most scheduling algorithms have a concept of priorities:

• We would sometimes like to reassign resources from lower-priority to higher-priority tasks, hence the need for preemption.
• Schedulers often adjust priorities based on resource usage, wait times, or deadlines. Who assigns them initially? Who can adjust them?
• Is the scheduling priority associated with the rocon service requesting resources? Or, should every resource request have its own associated priority?

Current Resolution

• Priorities are provided by the services (this is where the requester will be called from) or the solution's configuration of that service.

• Added a priority field to the Request message (rocon_msgs#43).

Discussion Thread

• (Jack) Since we are assuming a cooperative relationship between the scheduler and its requesters, I suggest that priorities be associated with each requester, initially be assigned by that requester, and subsequently adjusted by either the requester or the scheduler.

  • (Daniel) Yes, I'd planned on having that as part of the entire 'solution' configuration. It's beyond the awareness of a single service, and the resource manager isn't pre-aware of solutions either.

• (Jack) We need to define the semantics of priorities. I generally prefer that higher-numbered priorities be more-favored by the scheduler, but many systems differ in that respect, so it needs to be spelled out explicitly. Also, I suggest that we make them signed: int16 instead of uint16. That way, the default value of zero is in the middle of the priority range. This and another minor scheduler_msgs API change proposal are mentioned in issue robotics-in-concert/rocon_msgs#41 for further discussion and to track any changes we decide to make.

  • (Daniel) Works for me.

• (Daniel) Re every resource request having an assigned priority. I think this is necessary, services may need a low priority robot for a particular non-essential aspect of the service and a high priority for another. Shall we confirm this and add to the current resolution?

  • (Jack) Yes. Adding a priority to each Request is clearly a good idea. We can move it there from the SchedulerRequests message, and think about whether a per-requester base priority should also remain in that message. That could be useful as a default priority for new requests.

• (Daniel) Do we have any need for the scheduler to internally modify priorities yet? I'm guessing this is like bumping priorities for resources that have been waiting a long time. I think first iteration we should not worry about this, but definitely later it might be nice to have a scheduler algorithm that works from the default provided by the service in this way.

  • (Jack) I have not written a real scheduler yet, just message handling with some unit tests. Based on my limited experience with operating system schedulers decades ago, I would recommend that the scheduler be free to adjust request priorities using whatever criteria it considers appropriate. Having per-request priorities makes that possible. There are some tricky questions about how simultaneous request updates from both the requester and the scheduler should be resolved. Let's discuss that on the ../Requests page.