Messages in this thread | | | Date | Fri, 04 Aug 2006 13:02:59 -0400 | From | Shailabh Nagar <> | Subject | Re: [ProbableSpam] Re: [RFC, PATCH 0/5] Going forward with Resource Management - A cpu controller |
| |
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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |