Adaptive partition scheduling

Hi all,

I’m playing around with APS. What I want is to have a thread running in a budget of 20%.

System: 80
Testing : 20

I wanted to test if the critical thread is fired when the 20% level is reached. The testing partition has only one thread running doing a while(1).

When I do a aps show, the free time of the system partition is given to the testing partition.

Two questions:

  1. Will the cirtical thread execute when it reaches the 20%? Or will the free time of the system partition cancel this out? (I hope not!)
  2. How do I create a critical thread?

What have now is this:

creation_data.budget_percent = 20;
creation_data.critical_budget_ms = 10; = "testing";
coid =	ChannelCreate(0);

ret = SchedCtl( SCHED_APS_CREATE_PARTITION, &creation_data,

All goes well next i create two threads and make them join the partition, one is the ‘normal’ thread that contains the while loop and the other one I mark as critical:


join_partition(); /* this goes fine */



join_partition(); /*goes fine);

ret = SchedCtl(SCHED_APS_MARK_CRITICAL,&crit,sizeof(crit));

/* ret returns okay */

printf(" critical thread running\n" ) /* never gets here! */


Any ideas?

A question occured to me that maybe you already know. If a thread is running in a partition with %20, that does not limit it to %20 of the cpu, just guarentee’s it will have %20. So if you are running in an “empty” machine, should the critical event pulse occur when you pass the %20 mark, or or only if you are bumping up against it as a limitation?

It guarantees the 20%, if for some reason it cannot consume more then 20% (i.e no free time that can be divided) the critical thread is allowed to run in the critical portion of that partition.

To be more clear:

aps -create twenty_plus_10_ciritcal -b20 -B10

I have 20% budget, and i have 10ms to run a thread within the partition regardless that it has exceeded its 20% budget.

There are different settings that allow for different methods for dividing the free time. There was no flag (I could not find it) that prevents the 20% budget to ‘borrow’ free time of other partitions.

(btw if your critical thread runs out of 20ms, the partition is bankrupt. When this occurs, a thread may execute to handle that event with some sort of super state that it allows it to execute)

Hope that helps:)

No there is no flag. Why would you want this?

It is not really “borrowing” anything from the other partitions, it is more like the guy with a rich neighbor who one day notices that they have put a very nice piece of furniture out for the trash collector and takes it home (would you characterize this as “borrowing” from the rich neighbor?).

Not sure what you mean here, but it doesn’t sound correct.

The document says that when bankruptcy occers, the kernel generates an event. This event is recieved by a thread that can perform corrective actions or reboot or what ever. This happend afther the critical time has exceded its limit.

But to get back to the free time part, what if I have a hard real-time control loop that i know should never take longer then its budget. If it does something is wrong for instance sensor errors or a programming error what not. By not allowing it to borrow free time, the critical thread gets run time and I can notify some sort of execption handler that the system execeded its deadline. As such, I’m using the partition scheduler to guard the deadlines.

When the system is allowed to borrow free time; I cannot determine it used up more then its budget. (at least not with the in kernel mechanisms)

So in other words, what I realy want is to disable the adaptive beheaviour of the scheduler. If the system needs more time then its budget: things are wrong.

Furthermore, the question asked earlier about why the thread does not recieve the critical event is that its not implemented yet. I tested the bankrupt event and that works fine.

OK, I see what you’re asking. What you are asking for (I think) is the ability to be notified when a partition exceeds it’s budget (within a single window size I presume).

This would be a useful feature, but is not currently implemented. I believe it is planned (there is some gear for having threshold triggers).

Until then, a possible work-around would be to have a monitor thread that polls to do this (grungy I agree, but if you need it now). As long as the polling period is fast enough for your detection requirements, then it should be workable.