What happens on timeslice overrun?

[Udo A. Steinberg]

On Fri, 23 Sep 2005 17:48:51 +0200 Rene Wittmann (RW) wrote:

RW> > What you want is an atomic way of checking for a deadline 
RW> > miss and acting upon the result of that check. But such 
RW> > functionality does not exist. There is currently no way you 
RW> > can prevent the above scenario where the deadline miss occurs 
RW> > after the check but before (or while) you go to sleep via next_period.
RW> >
RW> I think for l4_rt_next_reservation there is such a "check" in the kernel by
RW> passing the timeslice number you think you're on as argument to this call.
RW> Maybe one could include such functionality for l4_rt_next_period by passing 
RW> the period you're waiting for as argument. This would give a quite useful 
RW> improvement :-)

Note that l4_rt_next_reservation is built on top of l4_thread_switch, which
provides ample register space in the L4 ABI for passing parameters like the
timeslice number. However, l4_rt_next_period is built on top of l4_ipc and
register space for argument passing is exhausted. To implement your suggestion,
we would need a 64-bit register (or two 32-bit registers) available in order
to pass the point in time of the next period to the kernel.

There are a number of ways to deal with this issue:
1) pass the additional parameter on the stack - this opens a can of worms
   wrt. the stack not being mapped and consequential page-faults. Yuck.
2) redefine the IPC registers such that the time parameter can be passed
   to the kernel - then we lose the ability to combine next_period with
   an IPC call, which is quite undesirable.
3) Move to an ABI with more register space, e.g., L4 X.2

Now I don't see 3) happen here anytime soon, so I don't know how to best
fix this in a nice way.

RW> > So what you have to do instead is: upon detecting a deadline 
RW> > miss, the preempter thread should ex_regs the thread with the 
RW> > deadline miss (thereby cancelling the l4_rt_next_period/IPC 
RW> > operation). When you return from next_period, you can check 
RW> > if you've been ex_regs'd out of it or whether the call 
RW> > returned regularly at the beginning of your new period, e.g, 
RW> > by checking the global variable that you already have.
RW> > 
RW> But if I detect it right after returning from l4_rt_next_period, it's
RW> already
RW> too late. One could say: skip the next call, but this would in worst case
RW> lead to an execution time 50% longer than the expected one (skip every
RW> second
RW> l4_rt_next_period). That's a great pity!

When you cancel an ongoing IPC operation using l4_ex_regs, the operation
will return with L4_IPC_RECANCELED or L4_IPC_SECANCELED, depending on whether
the ex_regs happened during the send or receive phase. If the IPC waits for
the beginning of the next period, then that "wait" should be cancelled as
well. Therefore, your code could look like this:

error = l4_rt_next_period (...);
if (error == L4_IPC_RECANCELED || error == L4_IPC_SECANCELED) {
  /*
   * Preempter aborted the next_period call upon deadline miss and I'm
   * now already in my next period (the one I originally wanted to wait
   * for using this next_period call).
   */
} else {
  /*
   * next_period succeeded. I waited until the next period and it has
   * now begun. The preempter didn't cancel the call so obviously no
   * deadline miss has occurred.
   */
}

This isn't as nice as the solution described above, but it does work with
the L4 V.2 API, which Fiasco currently uses.

-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/20050923/c00d08a2/attachment-0001.sig>