[LITMUS^RT] Container implementation idea

[Björn Brandenburg]

On Feb 27, 2012, at 3: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.

I've finally had a chance to look at this in more detail.Very nice, it looks good to me. In large parts, it mirrors closely what I had in mind. I think, integrating with Linux's container hierarchy would be a very nice feature if it can be done without creating too much of a maintenance headache.

Two things I might add. 

> To put it all together, a scheduling decision works as follows: […]
> 
> Some decisions will work in reverse. […]

When I played around with designs for hierarchical scheduler designs in the past, I ran into nasty locking issues in this regard. If you globally lock the entire hierarchy, then you'll have undesirably high overheads. If you allow locking on a more finely-granular basis, you'll have a hard time sorting out locking orders for operations moving in opposite directions. You might want to flesh this out in the next design iteration before coding the entire framework.

Secondly, did you plan to allow tasks to be in more than one container at any time? For example, the Raj's resource kernel work had a notion of "firm reservations", where a task would be allowed to compete with other tasks for idle capacity after exhausting its own reservation. This could be implemented by adding a task both into a, say, G-EDF container for its reserved capacity, and into a best-effort round-robin or CFS container to share background capacity when available. While something like this certainly isn't important for the first version, it might be nice to choose a design that doesn't make it too difficult in future versions.

Thanks,
Björn