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

[Shailabh Nagar]

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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/