containers development plans (July 10 version)

[Paul Menage]

On 7/10/07, Balbir Singh <balbir at linux.vnet.ibm.com> wrote:
>
> Well, it depends on how you define ugly. We could so something like
> the namespace approach, have something like
>
> struct mem_container_ptrs {
>         swap_list;
>         mem_container_ptr;
> };

I'm not quite sure what you're aiming for there. What would swap_list
represent?

I'm wondering if for both the per-page controller and the swap
controller, it would make sense to have a pointer back to an
appropriate process so we could get at a container pointer

Maybe something like:

- when an mm is created, store a pointer to the task_struct that it belongs to
- when a process exits and its mm_struct points to it, and there are
other mm users (i.e. a thread group leader exits before some of its
children), then find a different process that's using the same mm
(which will almost always be the next process in the list running
through current->tasks, but in strange situations we might need to
scan the global tasklist)

Then rather than having to have a pointer in the mm for either the
page controller or the swap controller (and the consequent hassles of
having refcounts from mm_structs to containers), you can just use the
container membership of mm->owner.

>
> Although, I agree that per container swap is important, I feel that
> we should add in the functionality, once we have basic page based
> memory controller. It would make the whole setup easier to test
> for functionality and performance.

We don't really need to wait for a working page-based memory
controller to be able to test a swap controller - cpusets gives memory
controls too, albeit on a much coarser granularity.

Paul