On 07/12/2012 11:37 AM, Osier Yang wrote:
On 2012年07月12日 17:19, Hu Tao wrote:
> On Thu, Jul 12, 2012 at 05:03:52PM +0800, Osier Yang wrote:
>> Setting hard_limit larger than previous swap_hard_limit must fail,
>> it's not that good if one wants to change the swap_hard_limit
>> and hard_limit together. E.g.
>>
>> % virsh memtune rhel6
>> hard_limit : 1000000
>> soft_limit : 1000000
>> swap_hard_limit: 1000000
>>
>> % virsh memtune rhel6 --hard-limit 1000020 --soft-limit 1000020 \
>> --swap-hard-limit 1000020 --live
>>
>> This patch reoder the limits setting to set the swap_hard_limit
>> first.
>> ---
>> src/qemu/qemu_driver.c | 26 +++++++++++++-------------
>> 1 files changed, 13 insertions(+), 13 deletions(-)
>>
>> diff --git a/src/qemu/qemu_driver.c b/src/qemu/qemu_driver.c
>> index dc04d13..1abdd27 100644
>> --- a/src/qemu/qemu_driver.c
>> +++ b/src/qemu/qemu_driver.c
>> @@ -6625,43 +6625,43 @@ qemuDomainSetMemoryParameters(virDomainPtr dom,
>> for (i = 0; i< nparams; i++) {
>> virTypedParameterPtr param =¶ms[i];
>
> Does this patch make any difference if the order of elements of params[]
> doesn't change?
Oops, right. I rushed, except qemu, lxc openvz also support memtune,
means I need a v2 anyway. Thanks.
One more thing. If the limit goes down it has to be set in the order:
1. soft_limit
2. hard_limit
3. swap_hard_limit
because otherwise you'll get to the same problems. I had something like
this in mind:
for each parameter -- check if it can be set (according to the current
values):
- yes) set it
- no) check if the parameter blocking the current one is being changed
as well:
- no) fail
- yes) prefer the parameter blocking the current one
Few more approaches (just to get it out of my head):
- set the values twice with ignoring errors in the first pass (ugly)
- check and sort all the parameters and then change them (overhead?)
- set the values to max/unlimited and then set them in a predefined
order (soft, hard, memsw).
Have a nice day,
Martin