From: Paulina Szubarczyk <email@example.com>
To: "Roger Pau Monné" <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org,
Dario Faggioli <email@example.com>,
Mina Naghshnejad <firstname.lastname@example.org>
Subject: Re: Outreachy bite-sized tasks
Date: Wed, 20 Apr 2016 12:06:48 +0200 [thread overview]
Message-ID: <1461146808.10108.25.camel@localhost> (raw)
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 .
> Could you elaborate on TRDCS? I've tried googling for it, but nothing came
I mistyped TRDCS, I meant putting trace points in the application to
measure the time spent in each place as shown in the talk. 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 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  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?
> 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:
> >  http://lxr.free-electrons.com/source/drivers/block/xen-blkback/blkback.c
> >  http://xenbits.xen.org/gitweb/?p=xen.git;a=blob;f=xen/include/public/io/blkif.h
> >  https://events.linuxfoundation.org/sites/events/files/slides/20131025%20-%20Storage%20Performance%20PDF.pdf
>  https://www.kernel.org/doc/Documentation/block/null_blk.txt
Xen-devel mailing list
next prev parent reply other threads:[~2016-04-20 10:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-23 15:32 Outreachy bite-sized tasks Roger Pau Monné
2016-03-23 16:38 ` Paulina Szubarczyk
2016-03-23 18:21 ` Dario Faggioli
2016-04-01 10:05 ` Paulina Szubarczyk
2016-04-01 13:35 ` Roger Pau Monné
2016-04-20 10:06 ` Paulina Szubarczyk [this message]
2016-04-25 18:58 ` Konrad Rzeszutek Wilk
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).