Re: [Xen-devel] Outreachy bite-sized tasks

[Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx>]

On Wed, Apr 20, 2016 at 12:06:48PM +0200, Paulina Szubarczyk wrote:
> On Fri, 2016-04-01 at 15:35 +0200, Roger Pau Monné wrote:
> > Please don't top post, it breaks the flow of the conversation.
> > 
> > I'm also adding Anthony (one of the QEMU/Xen maintainers).
> > On Fri, 1 Apr 2016, Paulina Szubarczyk wrote:
> > 
> > > Hi Roger,
> > > 
> > > An another point that needs to be filled up in the application is 
> > > timeline.
> > > I made the proposition of it, I am not sure if it should be more complex. 
> > > Could you look at it in your free time?
> > > 
> > > Timeline:
> > > 
> > > 22 April - 22 May [Before the intership]
> > >  * Elaborate performance measurement methodology. That may include 
> > > putting trace
> > >     points using TRDCS and performing read operation with varying block 
> > > sizes on 
> > >     different storage devices as in [3].
> > 
> > Could you elaborate on TRDCS? I've tried googling for it, but nothing came 
> > up.
> I mistyped TRDCS, I meant putting trace points in the application to
> measure the time spent in each place as shown in the talk[3]. But is I
> did more research concerning the measurement I think that the good idea
> would be using fio and make similar test as Adriana did during her
> OWP[4] when she worked on implementing multi-queue support for
> xen_backend in Linux.  
> 
> > Also, I think it would be good to write down which tool are you going to 
> > use in order to perform those measurements, and how/which block sizes are 
> > you going to test. Also keep into account that apart from block sizes you 
> > also have to take into account the number of parallel workers and the 
> > queue depth of each one.
> > 
> > Regarding the different storage devices, we usually did benchmarks using a 
> > ramdisk, but Linux intorduced a null-block device [0] not long ago that I 
> > think could be used to model different storage devices without actually 
> > having to buy them.
> I make myself familiar with the protocol and I debug the qdisk during
> attaching one of ram devices to follow how it works. I also wondered if
> maybe I could make a change to 'xl create' such as when it is run in the
> qemu debug mode doesn't terminate when Device Mode isn't ready yet,
> because sometimes is hard to catch the moment when the connection to
> gdbserver is possible.
> 
> Whereas I saw the implementation of indirect descriptors and the
> multi-queue support by creating multiple rings, I couldn't find the
> information of grant copy. Do you mean by that hypervisor-driven copy of
> grant pages between domains instead of mapping them? 

Yup. The hypervisor does the memcpy. The grant mapping system has an impact
that is felt when you are done with the grant - you need to unmap it.

And when you unmap it - you need to flush out the virtual address out of
the guests vCPUS (if the guests are runninig) - otherwise the CPU could
use an stale virtual address (they are cached) and reference an memory
that now points to somewhere else. Hence the unmap means also doing an
TLB shootdown which is expensive as it flushes out the CPU cache.

There have been improvements in this - David Vrabel had posted some patches
for this I think..

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel