| Re: containers development plans (July 10 version) [message #14798 is a reply to message #14797] |
Wed, 11 July 2007 06:55   |
Paul Menage
Messages: 642
Registered: September 2006
|
Senior Member |
|
|
On 7/10/07, Balbir Singh <balbir@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
|
|
|
|
OpenVZ Forum
Members
Search
Help
Register
Login
Home
