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

From: Kirill Korotaev
Date: Fri Aug 04 2006 - 12:05:07 EST


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/