[Xen-ia64-devel] [PATCH][RFC] [0/2]Consider steal time for IA64-PVdomain

[Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx>]

Hi, 

 This patch intends to consider steal time accounting.
This functionality is already implemented in x86/PV-domain.
The steal time means consider the state 
"vcpu is ready to run but not allocated CPU resources by hypervisor."
Previously, this state time is accounted to running process of domain 
at domain_context_switch occured.
It makes over counting, especially cpu-intensive process.
because cpu-intensive process are keeping running state, 
and it keeps stay in all domain context switch time.

This patch effect can be seen from guest OS by following
1)cat /proc/stat (end colum of cpu)
2)procps (at least 3.2.6)
    vmstat (can be seen as cpu st)
    top    (can be seen as st x.x%)

This patch composed 2 items 
1) hyper to PV-guest data shareling.
   (done by arch_shared_info)
2) PV-guest steal_time consideration
   (newly create function of consider_steal_time())

This patch is consist of 2.(see following mail)
1 for just port the linux/arch/ia64/kernel/time.c
2 for patch(hypervisor and PVdomain is includes in one)


I want to ask following 1 item.I welcome any comments.

1)__copy_to_guest 
x86 implementation it uses 
Hypercall of VCPUOP_register_runstate_memory_area at boot time 
and __copy_to_guest(every context switch).

but IA64 case, __copy_to_guest causes overhead.
Because currently copy_to_guest only supports for hypercall only on IA64.
for this reason copy_to_guest uses xencomm, it makes overhead for 
address translation.
For this reason, I use arch_shared_info at this moment.
This makes just copy data and less overhead.

For same type of implementation like x86,
it needs to support copy only (not address translation) function 
"copy_to_guest".
If any idea suggested, I plan to rewrite this patch.
Also some patches for copy only copy_to_guest is welcome.

Anyway,
shared_info uses MAX_VIRT_CPUS array.
Is this permitted to use MAX_VIRT_CPUS array in arch_shared_info? 

Signed-off-by: Atsushi SAKAI <sakaia@xxxxxxxxxxxxxx>


Thanks
Atsushi SAKAI




_______________________________________________
Xen-ia64-devel mailing list
Xen-ia64-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-ia64-devel