[LITMUS^RT] Container implementation idea

[Andrea Bastoni]

On 02/27/2012 03:40 AM, Jonathan Herman wrote:
> I will be adding container support to litmus over the next
> year. Exciting. My goals are to support a hierarchical container
> scheme where each container can have its own scheduling policy and a
> single container can be run on multiple CPUs simultaneously.
> 
> This is my idea and I would love it to be critiqued.

Sorry for the late reply. I haven't found a decent moment to think about this in
more detail.

I like what you proposed and the draft structures and schedule logics look good
to me. I'd just add a couple of things.

> *-- Interface --*

[snip]

> I intend to completely copy the container proc interface from
> Linux.

The cgroup interface in Linux is now using the sysfs file system. I think it's
way better than the proc interface for complex directory nesting and reliable
input and output (I had troubles in the past using the proc interface to output
complex stuff). Since we might want to increase the complexity of hierarchical
containers in the future, it may be nice to shift to a sysfs structure from the
beginning.

[snip]

> To put it all together, a scheduling decision works as follows:
> 1. Linux calls into Litmus's schedule method.
> 2. Litmus calls schedule on the base container.
> 3. The base container returns some rt_task.

This may be a good starting point for a merge/support of the preempt_rt patch
(if, in the future, we believe this is worth/beneficial). One of the main issue
that we have with the preempt_rt patch is that timers run threaded (force irq
threading is enabled) at lower priority than Litmus tasks (that actually rely on
timers). A "higher-priority" container to schedule irq kthreads may be an
interesting approach; and it may also extend the CPU_MASTER approach with the
definition of different scheduling policies for irq-handling.

Thanks,

- Andrea