WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] [RFC][PATCH 12/13] Kemari: use signal to save qemu state

Yoshiaki Tamura wrote:

> Stefano Stabellini wrote:
>> Ian Jackson wrote:
>>
>>> Stefano Stabellini writes ("Re: [Xen-devel] [RFC][PATCH 12/13] Kemari: use 
>>> signal to save qemu state for Kemari"):
>>>> I did a couple of quick tests and it seems that signals are faster then
>>>> xenstore but still xenstore offers good performances.
>>>>
>>>> I measured the time using rdtsc at the sender size and at the receiver
>>>> size, the difference between the two values is the following:
>>>>
>>>> signals:   368836
>>>> xenstore: 1984632
>>> This is with an unloaded xenstored, I take it.
>>
>> Yes
> 
> Thanks for measuring the numbers.  It made things clear.
> I think we need a signal-based interface as Ian said previously.
> 
> On our test environment, AMD Barcelona 2.3GHz, the total cpu cycles of Kemari 
> in 
> userland when running I/O intensive applications is around 3000000.
> Although Xen transferring code and QEMU saving code is processed 
> concurrently, 
> using xenstored for staring QEMU portion would lower the performance. 
> Especially if the xenstored gets slower when items are loaded.
> 

Using an event channel to notify qemu in a stubdom that a particular
event occurred improves things a lot: it is even faster than signals!

event channel: 20880

performances using an event channel with qemu as a process in dom0 are
about the same.

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

<Prev in Thread] Current Thread [Next in Thread>