The implementation of CPU reservation server

[Udo A. Steinberg]

On Wed, 3 Jun 2009 02:25:15 +0800 Sean (S) wrote:

S> I got confused in several points
S> 
S> Currently, I don't trace how to implement timeout in Fiasco. I assume when
S> it expired, the timeout handler will execute.

There exists a timeout base class and 3 derived classes for specific
timeouts, namely IPC timeouts, timeslice timeouts and deadline timeouts.
When a timeout expires, the virtual method ::expired is called; all
derived classes overwrite this method such that code specific to the timeout
type is executed.

S> 1. If timeout handler is executed inside Fiasco
S>    => Fiasco needs to determine which group of threads needs to change
S> state and the information about time interval. So I need to port all
S> control rules of control server into Fiasco?
S>    => Or I need to maintain a list in Fiasco and update this list from the
S> control server on top of Fiasco. But how to do it?

Have a look at how the current real-time scheduling framework controls
deadlines, period etc. from user space. You would have to design a similar
interface that downloads interval start/end times and affected threads into
the kernel.

S> 2. If timeout handler is executed as a user thread on top of Fiasco. How
S> the control server on top of Fiasco changes the other user thread's state?
S>    => I need to provide the system call interface or other issues to
S> change the user thread's state.
S>    => Can I implement it by fixing the existent system call thread_ex_regs
S> or I need to add a new system call?

The simplest thing here is to add a new system call that allows setting and
clearing the Thread_ineligible flag of threads from user mode. I do not
recommend overloading the ex_regs system call because that only complicates
things.

S> If I use the system call thread_ex_regs, I think it will have the problem:
S>    If there are a lot of threads needed to change the state, I need to
S> call the system call many times for every thread. it seems to be a huge
S> overhead here.

Correct. But you can design your system call such that you change the state
of multiple (all?) affected threads at once. However, note that the more
threads change state on interval boundaries, the more latency you will add
in the kernel even if you can do it with just a single system call
invocation.

If this is a problem, you could take an alternate approach to the whole
problem: You could maintain a run queue for each time interval and when one
interval ends and another starts, you could just switch run queues. While
this removes the need to track eligible/ineligible state of threads, you now
have to decide into which run queue a particular threads should go when it is
ready. This approach requires less thread state changes, but requires much
more memory.

Cheers,

	- Udo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20090602/9962b52d/attachment-0001.asc>