The implementation of CPU reservation server

[Sean]

Dear

Now I start to write my own  scheduling framework.
But I got some questions here...

Because the policy to decide the time interval in control server is
dependent on the execution time of the threads in each group. I need to get
the information about the execution time after last context switch.
    I had traced the source code about the variable *_consumed_time* in
class Context. This variable will be updated in *
Thread::handle_timer_interrupt()* function.
    My question is
1. Can I use this variable directly? What's the accuracy of this variable?

2. *Thread::handle_timer_interrupt()* function will be called in *
irq_handler()* function in ARM platform.
    I can't find any information about this function. When will this
function be called? Where is the related source code of calling/registering
this function?

Thanks for your kindness.

Best Regards,
Sean

On Wed, Jun 3, 2009 at 3:20 AM, Udo A. Steinberg <udo at hypervisor.org> wrote:

> 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
>
> _______________________________________________
> l4-hackers mailing list
> l4-hackers at os.inf.tu-dresden.de
> http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://os.inf.tu-dresden.de/pipermail/l4-hackers/attachments/20090609/7f546e64/attachment.htm>