Notes on things thusly far

These are in no particular order, and are genuinely nothing more than me making mental notes to myself as I go along, for inclusion in my write-up

The issues

• sched_param is defined in rtl_sched.h. But /only/ if __cplusplus is defined. Elsewises, the defn is pulled from a vanilla linux kernel header... And since we don't want to tread on anyone's toes, we'll just start a new name. Since rtl_sched_param is used as the _actual_ scheduling keeping-track thingy, I've chosen to override that instead.
• This means everything is backwardly compatable, but I need new pthread_attr_setschedparam, pthread_attr_getschedparam, pthread_getschedparam, pthread_getschedparam for aperiodic tasks, since function overloading isn't allowed in C. Grrr.
• The Never server is as much use as a chocolate teapot, but is great to find out if the rest of my code is working right.
• The phrase "unknown scheduler requested - task ousted for not playing nice with the other kids" should _not_ appear with regards to the vanilla linux kernel, as that causes a panic.
• Throughout this whole exercise, it's really really easy to lock the machine hard; if at any point an RT task runs away, there is no way to make the vanilla kernel ever run again, as the RT task is at higher priority and anything that a punter such as I is allowed to do.
• Event-driven schedulers are good. I must make extended use of timers to implement such things. A timer also solves the problem whereby I need to keep track of what the sporadic server has been doing.
• A task with no budget left is low priority, not blocked. It can still bomb the machine.
• Perhaps I should make these damn servers actually work, then I'd be able to run the linux kernel at a high enough priority that I'd be allowed to oust the RT kernel when I do something else that 's stupid?
• Alternatively, I could write something into the scheduler so that when a task runs away in a bad way, it would automatically get killed. Unfortunately, requries solution to halting problem first. I shall work on that.
• I'm allowed 16 one-shot timers to be actually set up. Stupid intel. Stupid unix.
• Extension: If I set up any of the oneshots, then they throw a signal in my general direction when the time is up. If I'm sleep()ing while I'm waiting to catch it, then I won't wake up. I'll just finish the sleep, _then_ start processing the queue of signals I've collected. Looks like I'm gonna have to go lower-level than the vanilla oneshots. Bugger
• Extension 2: Perhaps if I just do that block_until_its_my_time thing...
• Dynamic memory allocation in RT-space is both stupid and dangerous. Don't do it. You're not allowed to keep track of tasks with replenishments pending using a linked list
• Note to self: replenishements on the sporadic server will never be queued up out-of-order, because time flows in a straight line in a computer. You don't need to sort the queue every time. Adding more weight to the static-array-with-two-pointers-rotating-round-it argument

And here's the deisgn as I'm currently considering it:

1. When a task goes onto the CPU, a very high priority oneshot is set up, so thread will be ousted if it overshoots its budget
2. When a task comes off the CPU, if it was naturally removed from the CPU [ie, not ousted by high-priority oneshot], then the oneshot must be cancelled
3. One case for each policy:
   • Never Server: We continue as we were before
   • Sporadic Server: The task must have a oneshot created that goes off at (period - time_just_spent_on_cpu) that replenishes (time_just_spent_on_cpu) time units
   • Deferred Server: We continue as we were before
   • It should be possible to glue arbitrary functions here, for policies as-yet-unknown based on time when task was running
4. The budget replenisher will be in parts severally:
   • One part, that has a collection of all timers that need to go off, including what task needs the replenishment, how much it needs to have replenished, and when that replenishment needs to happen. This is what will be called by the main rtlinux scheduler to set up oneshots
   • Another part that is woken up when the timer goes off, and replenishes the relevant thread
   • It should be possible to glue arbitrary functions to the replenishment part, so that people can implement policies based on when the last replenishment was.
   • There will be a function for the deferred server that just sets up another one-shot
5. Indepent queues of tasks pending replenishment for each server will probably be a good thing; it'll mean I don't have to sort arrays

This page is and

My Website Starts Here

This page last modified: 2003-06-26