Re: [RFC, PATCH 0/5] Going forward with Resource Management - A cpu controller

[Rohit Seth <rohitseth@google.com>]

On Fri, 2006-08-04 at 20:03 +0400, Kirill Korotaev wrote:
 
> > Doesnt the ability to move tasks between groups dynamically affect
> > (atleast) memory controller design (in giving up ownership etc)?
> we save object owner on the object. So if you change the container,
> objects are still correctly charged to the creator and are uncharged
> correctly on free.
> 

Seems like the object owner should also change when the object moves
from one container to another.

> > Also if we need to support this movement, we need to have some
> > corresponding system call/file-system interface which supports this move 
> > operation.
> it can be done by the same syscall or whatever which sets your
> container group.
> we have the same syscall for creating/setting/entering to the container.
> i.e. chaning the container dynamically doesn't change the interface.
> 
> >>BTW, do you see any practical use cases for tasks jumping between 
> >>resource-containers?
> > 

I think the ability to move file backed memory from one container to
another is useful.  This allows appropriate containers to get charged
based on the usage pattern.  Though this (movement between containers)
is not something that should be encouraged.

> > 
> > The use cases I have heard of which would benefit such a feature is
> > (say) for database threads which want to change their "resource
> > affinity" status depending on which customer query they are currently handling. 
> > If they are handling a query for a "important" customer, they will want affinied
> > to a high bandwidth resource container and later if they start handling
> > a less important query they will want to give up this affinity and
> > instead move to a low-bandwidth container.

hmm, would it not be better to have a thread each in two different
containers for handling different kind of requests.  Or if there is too
much of sharing between threads, then setting the individual priority
should help.

> this works mostly for CPU only. And OpenVZ design allows to change CPU
> resource container  dynamically.
> But such a trick works poorly for memory, because:
> 1. threads share lots of resources.
> 2. complex databases can have more complicated handling than a thread per request.
>   e.g. one thread servers memory pools, another one caches, some for stored procedures, some for requests etc.
> 

Any resource movement between containers should be at best efforts.  The
stats will tend to be more inaccurate (which I think is okay) as the
sharing between resources across increases.

> BTW, exactly this difference shows the reason to have different groups for different resources.
> 

Well, for a set of processes that are sharing a set of resources
perfectly, it would be okay to combine all such resources in a single
container.  But for a shared resource, like file(that spans across
processes in different containers), it could be useful to have a
stand-alone container.

-rohit 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/