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

[Kirill Korotaev]

> > OpenVZ assumes that tasks can't move between task-groups for a single 
> > reason:
> > user shouldn't be able to escape from the container.
> > But this have no implication on the design/implementation.
>
>
> 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.

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

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

Thanks,
Kirill

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