[LITMUS^RT] Container implementation idea

[Jonathan Herman]

Work is now restarting on this (internships...).

On Sat, Mar 17, 2012 at 8:57 AM, Andrea Bastoni <bastoni at cs.unc.edu> wrote:
> On 02/27/2012 03:40 AM, Jonathan Herman wrote:
> 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.
>

I will try and come up with an idea for how this would integrate and
send it to the mailing list.

>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.

This too.

> 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.

I'll keep this in mind. It probably won't come into the first version.

I'm now leaning towards the first version being more of a toolkit
which can be used in new plugins. After its easy to make new container
plugins, we'll see about moving container stuff higher up the decision
tree so that the scheduler can use containers to manage other
resources like interrupts in the background.

--
Jonathan Herman
Department of Computer Science at UNC Chapel Hill