xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Paulina Szubarczyk <paulinaszubarczyk@gmail.com>
To: xen-devel@lists.xenproject.org, roger.pau@citrix.com
Cc: sstabellini@kernel.org, wei.liu2@citrix.com,
	Paulina Szubarczyk <paulinaszubarczyk@gmail.com>,
	ian.jackson@eu.citrix.com, P.Gawkowski@ii.pw.edu.pl,
	dvrabel@cantab.net, david.vrabel@citrix.com,
	anthony.perard@citrix.com
Subject: [PATCH v3 0/2] qemu-qdisk: Implementation of grant copy operation.
Date: Wed, 22 Jun 2016 10:38:51 +0200	[thread overview]
Message-ID: <1466584733-19459-1-git-send-email-paulinaszubarczyk@gmail.com> (raw)

Hi,

It is a proposition for implementation of grant copy operation in qemu-qdisk and 
interface in libxc/libs. 

Changes since v2:
Interface:
- dropped the changes in libxc/include/xenctrl_compat
- changed the MINOR version in Makefile
- replaced 'return -1' -> 'abort()'in libs/gnttab/gnttab_unimp.c
- moved the struct 'xengnttab_copy_grant_segment' to 
  libs/gnttab/include/xengnttab.h
- added explicit assingment to ioctl_gntdev_grant_copy_segment 
  to the linux part

qemu-qdisk:
- to use the xengnttab_* function directly added -lxengnttab to configure
  and include <xengnttab.h> in include/hw/xen/xen_common.h
- in ioreq_copy removed an out path, changed a log level, made explicit 
  assignement to 'xengnttab_copy_grant_segment'
* I did not change the way of testing if grant_copy operation is implemented.
  As far as I understand if the code from gnttab_unimp.c is used then the gnttab 
  device is unavailable and the handler to gntdev would be invalid. But 
  if the handler is valid then the ioctl should return operation unimplemented 
  if the gntdev does not implement the operation.


Changes since v1:
Interface:
- changed the interface to call grant copy operation to match ioctl
	int xengnttab_grant_copy(xengnttab_handle *xgt,
                         	 uint32_t count,
                         	 xengnttab_grant_copy_segment_t* segs)

- added a struct 'xengnttab_copy_grant_segment' definition to tools/libs	
  /gnttab/private.h, tools/libxc/include/xenctrl_compat.h

- changed the function 'osdep_gnttab_grant_copy' which right now just
  call the ioctl

- added a new VER1.1 to tools/libs/gnttab/libxengnttab.map 

qemu-qdisk:
- removed the 'ioreq_write','ioreq_read_init','ioreq_read' functions 
- implemented 'ioreq_init_copy_buffers', 'ioreq_copy' 
- reverted the removal of grant map and introduced conditional invoking
  grant copy or grant map
- resigned from caching the local buffers on behalf of allocating the 
  required amount of pages at once. The cached structure would require 
  to have an lock guard and I suppose that the performance improvement 
  would degraded. 
 

For the functional test I attached the device with a qdisk backend to the guest, 
mounted, performed some reads and writes.

I run fio tests[1] with different iodepth and size of the block. The test can be 
accessed on my github[2] but mainly after the warm up I run for 60 seconds:
    fio --time_based \
		--clocksource=clock_gettime \
		--rw=randread \
		--random_distribution=pareto:0.9 \
		--size=10g \
	    --direct='1' \
	    --ioengine=libaio \
		--filename=$DEV \
		--iodepth=$IODEPTH \
		--bs=$BS \
		--name=$NAME \
		--runtime=$RUNTIME >> $FILENAME
The test were repeated at least three times. 

[1] https://docs.google.com/spreadsheets/d/1E6AMiB8ceJpExL6jWpH9u2yy6DZxzhmDUyFf-eUuJ0c/edit?usp=sharing

[2] https://github.com/paulina-szubarczyk/xen-benchmark
    - multitest_with_iodepth.sh


Thanks and regards, 
Paulina

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

             reply	other threads:[~2016-06-22  8:43 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-06-22  8:38 Paulina Szubarczyk [this message]
2016-06-22  8:38 ` [PATCH v3 1/2] Interface for grant copy operation in libs Paulina Szubarczyk
2016-06-22  9:37   ` David Vrabel
2016-06-22  9:53     ` Paulina Szubarczyk
2016-06-22 11:24       ` Wei Liu
2016-06-22 14:19         ` Paulina Szubarczyk
2016-06-22 11:21     ` Wei Liu
2016-06-22 12:37       ` David Vrabel
2016-06-22 13:29         ` Wei Liu
2016-06-22 13:52           ` David Vrabel
2016-06-22 14:52             ` Wei Liu
2016-06-22 16:49               ` Wei Liu
2016-07-06 15:49                 ` Roger Pau Monné
2016-07-05 16:27               ` George Dunlap
2016-07-08 13:18   ` Wei Liu
2016-07-13  9:12     ` Wei Liu
2016-06-22  8:38 ` [PATCH v3 2/2] qdisk - hw/block/xen_disk: grant copy implementation Paulina Szubarczyk
2016-07-13 12:34   ` Paulina Szubarczyk
2016-07-14 10:37   ` Wei Liu
2016-07-15 10:28     ` Paulina Szubarczyk
2016-07-15 11:15       ` Wei Liu
2016-07-15 17:11         ` Anthony PERARD
2016-07-19 10:16           ` Paulina Szubarczyk
2016-07-15 16:55   ` Anthony PERARD
2016-07-19 10:51     ` Paulina Szubarczyk
2016-07-19  9:12   ` Roger Pau Monné
2016-07-19 10:12     ` Paulina Szubarczyk

Reply instructions:

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1466584733-19459-1-git-send-email-paulinaszubarczyk@gmail.com \
    --to=paulinaszubarczyk@gmail.com \
    --cc=P.Gawkowski@ii.pw.edu.pl \
    --cc=anthony.perard@citrix.com \
    --cc=david.vrabel@citrix.com \
    --cc=dvrabel@cantab.net \
    --cc=ian.jackson@eu.citrix.com \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).