What happens on timeslice overrun?

[Udo A. Steinberg]

On Sun, 14 Aug 2005 22:16:09 +0200 Rene Wittmann (RW) wrote:

RW> I have 2 questions on the RT part in DROPS:
RW> 
RW> 1.) I have 2 RT working threads, each with 3 timeslices:
RW> Thread 1: period=10ms 
RW>           ts1=30ms prio1=50
RW>           ts2=10ms prio2=30
RW>           ts3=20ms prio3=50
RW> 
RW> Thread 2: period=10ms
RW>           ts1=20ms prio1=40
RW>           ts2=5ms  prio2=30
RW>           ts3=10ms prio3=40
RW> 
RW> Assume both threads are ready at the same time.
RW> So thread 1 starts and does its work until it 
RW> releases the voluntarily or it's preempted by 
RW> its preempter-thread. So say it releases 
RW> voluntarily after 20ms. 

When you say "it's preempted by its preempter thread", do you mean the
situation when a preempter with a higher priority than the current thread
receives a preemption IPC from the kernel and thus preempts the current
thread?

RW> Who will get the left 10ms? I guess nobody.

When a thread is preempted (that means it gets involuntarily descheduled),
the remaining time quantum is saved and later restored when the thread is
scheduled again. If the thread yields its scheduling context (that means it
voluntarily gives it away), the time quantum is no longer available to
the thread. A yield can happen in two ways depending on the target thread
id specified:

1) if the target ID is the NIL_ID, then the thread yields its active
   scheduling context to noone - the time is effectively gone. This is
   what next_reservation does. Note that the kernel checks the user-specified
   ID, to guard against the case where a thread wants to yield its active
   scheduling context and the time quantum on that scheduling context expires
   simultaneously.

2) if the target ID is a valid thread ID in the system, then the action
   depends on whether the specified thread is ready to run:
   a) if it is, then the current thread donates the current scheduling
      context to the specified thread and that thread then becomes the
      current thread. This is similar to what happens during a donating IPC.

   b) if the specified thread is not ready, then the current scheduling
      context is gone, similar to 1)

RW> Or can I assign my left time to a specific 
RW> thread, say ts2 of thread 1, that is has 20ms 
RW> after recognizing that ts1 was finished 10ms 
RW> earlier?I could do with l4_rt_change_timeslice(), 
RW> but this would probably not work for the the 
RW> current period! (or yes?)

A thread can yield the current scheduling context to another thread as
described in 2a) above. Note that the thread will yield the current
scheduling context (which may not necessarily be the thread's own active
scheduling context). As an example consider:
A sends a donating IPC to B, now B runs on A's scheduling context. If B
yields to C, then C will run on A's time and B will not donate its
own scheduling context. If the current scheduling context is in fact
the active scheduling context of the donating thread, then realize that
the donating thread will likely encounter a timeslice overrun soon after
the yield (the donatee will consume the time quantum until it runs out).
If you'd rather avoid that, then the donatee will have to yield the
scheduling context back to the owner (the original donator) who then has
to yield it to noone.

Changes to the time quantum of a scheduling context are only visible
the next time that scheduling context becomes the current scheduling
context. That means if you change the current scheduling context, then
the change will not be visible immediately. 

RW> 2.) Consider we have a deadline miss. And we say 
RW> l4_rt_next_period(): would it wait for the beginning
RW> of the next (which means:
RW>   period 1: deadline miss
RW>   period 2: call next period (because we think we're
RW>             still in period 1)+ wait to end of period
RW>   period 3: normal work)
RW> Or do I have to care that we do not call 
RW> l4_rt_next_period() in case of a deadline miss?

If your thread misses its deadline right before it wanted to call
l4_rt_next_period, then l4_rt_next_period blocks the thread until
the end of the new period started due to the deadline miss. Since this
is likely not what the thread intended to do, it's the preempter's job
to handle that situation, e.g. by ex_regs'ing the thread out of it's
l4_rt_next_period call.

RW> BTW: I compiled the fiasco-kernel with apic+one shot 
RW> mode. But this should not be relevant for my question.

It is indeed not relevant.

-Udo.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20050814/7681ee7a/attachment-0001.sig>