Hi,
I agree with you. I check the hypercall time at creating.
The time was different because of several reasons.
Their reasons are the number of vcpus,
immediately after destroy and machines (Tiger and PRIMEQUEST and so on).
The hypercall takes several hundred mili seconds,
and it takes around 5 mili seconds with my new patch.
I think the reason of stopping network for several seconds is
ksoftirqd was not dispatched on dom0. dom0 is not preempt,
so I think dom0_max_vcpus=2+ is better.
If I specified dom0_max_vcpu=2, network response was sane while creating.
Signed-off-by: Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>
Best Regards,
Akio Takebe
>Hi Akio.
>At first I'm agree with you that the constant may needs
>to be reduced. The issue is what value is appropriate.
>
>Do you know how long the hypercall takes?
>Your description sounds like that the hypercall takes several
>seconds. So havling it seems just to halve the time which still
>stays the order of seconds. So it doesn't seem to solve your real
>issue.
>
>I suppose the hypercall should return in small time enough.
>The problem is what "enough" is compared to what?
>One candidate is vcpu time slice. Another possible candidate would
>be time related to tcp timeout.
>
>thanks,
>
>On Thu, Jul 17, 2008 at 04:13:17PM +0900, Akio Takebe wrote:
>> Hi,
>>
>> When I create a guest having large memory,
>> Some guests could not get network response for several seconds.
>> The issue is caused by xencomm_privcmd_memory_reservation_op().
>> To improve the response time, the attached patch reduces
>> MEMORYOP_MAX_EXTENTS.
>>
>> Signed-off-by: Akio Takebe <takebe_akio@xxxxxxxxxxxxxx>
>>
>> Best Regards,
>>
>> Akio Takebe
>
>> diff -r 3643a33de277 arch/ia64/xen/xcom_privcmd.c
>> --- a/arch/ia64/xen/xcom_privcmd.c Mon Jun 30 16:14:04 2008 +0100
>> +++ b/arch/ia64/xen/xcom_privcmd.c Fri Jul 18 01:00:05 2008 +0900
>> @@ -445,7 +445,7 @@ xencomm_privcmd_memory_reservation_op(pr
>> * increase adoptively measuring hypercall time.
>> * It might be over-kill.
>> */
>> -#define MEMORYOP_MAX_EXTENTS (MEMORYOP_XENCOMM_LIMIT / 4)
>> +#define MEMORYOP_MAX_EXTENTS (MEMORYOP_XENCOMM_LIMIT / 8)
>>
>> while (nr_extents > 0) {
>> xen_ulong_t nr_tmp = nr_extents;
>
>> _______________________________________________
>> Xen-ia64-devel mailing list
>> Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
>> http://lists.xensource.com/xen-ia64-devel
>
>--
>yamahata
reduce_hypercall_time.2.patch
Description: Binary data
_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel
|
Home