Re: Outreachy bite-sized tasks

From: "Roger Pau Monné" <roger.pau@citrix.com>
To: Paulina Szubarczyk <paulinaszubarczyk@gmail.com>
Cc: anthony.perard@citrix.com, xen-devel@lists.xenproject.org,
	"Dario Faggioli" <dario.faggioli@citrix.com>,
	"Mina Naghshnejad" <mina.naghshnejad@gmail.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>
Subject: Re: Outreachy bite-sized tasks
Date: Fri, 1 Apr 2016 15:35:41 +0200	[thread overview]
Message-ID: <alpine.OSX.2.20.1604011411070.9476@mac> (raw)
In-Reply-To: <CAMQpU2rsaSNMCJeyzAWNgL_PW4HrD8LthkcVspH9jSayWwKTTA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2581 bytes --]

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.

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 don't expect that you do all this now, but it is important to think 
about the different scenarios/benchmarks and plan ahead, so that you 
don't end up running benchmarks that are not useful.

>  * Gain a profound knowledge about implementation of xen-blkback in Qemu and Linux kernel.
> 
> 23 May - 6 June [Begin of the intership - up to two weeks]
>  * Prepare and improve performance measurement test.
>  * Gather and document the results.
> 
> 6 June - 23 August
>  * Base on the analysis and the task description implement performance improvement future 
>    inside of QEMU's xen-blkback.
>  * Prepare and run regression tests and continue performance measurement for 
>    each implemented feature.
>  * Document the results.
> 
> 15 August - 23 August [Close to the end]
>  * Sum up the work:
>    - indicate the obstacles
>    - form the conclusion and
>    - indicate future work.
> 
> References:
> [1] http://lxr.free-electrons.com/source/drivers/block/xen-blkback/blkback.c
> [2] http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/blkif.h
> [3] https://events.linuxfoundation.org/sites/events/files/slides/20131025%20-%20Storage%20Performance%20PDF.pdf

[0] https://www.kernel.org/doc/Documentation/block/null_blk.txt

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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