On 7/10/07, Balbir Singh <balbir@xxxxxxxxxxxxxxxxxx> 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
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
