Kirill Korotaev wrote:
>> 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 for block I/O bandwidth control since the priority of I/O requests can
also be changed dynamically pretty easily.
> 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.
>
True. Stuff like memory, open files etc. are harder to control since
you can't take back allocations that easily and sharing with other tasks is
possible.
> BTW, exactly this difference shows the reason to have different groups
> for different resources.
>
Good point.
> Thanks,
> Kirill
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
