From: Paulina Szubarczyk <paulinaszubarczyk@gmail.com> To: xen-devel@lists.xenproject.org Cc: roger.pau@citrix.com, wei.liu2@citrix.com, ian.jackson@eu.citrix.com, david.vrabel@citrix.com, sstabellini@kernel.org, anthony.perard@citrix.com, qemu-devel@nongnu.org, Paulina Szubarczyk <paulinaszubarczyk@gmail.com> Subject: [Qemu-devel] [PATCH v4 0/2] qemu-qdisk: Implementation of grant copy operation. Date: Tue, 2 Aug 2016 16:06:28 +0200 [thread overview] Message-ID: <1470146790-6168-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 v3: Interface: - revert to cast from xengnttab_grant_copy_segment_t to ioctl_gntdev_grant_copy. - added compile-time check to compare the libs xengnttab_grant_copy_segment_t with the ioctl structure. The patch relies on Wei patch introducing XENGNTTAB_BUILD_BUG_ON in libs/gnttab. qemu-qdisk: - qemu_memalign/qemu_free is used instead function allocating memory from xc. - removed the get_buffer function instead there is a direct call to qemu_memalign. - moved ioreq_copy for write operation to ioreq_runio_qemu_aio. - added struct xengnttab_grant_copy_segment_t and stub in xen_common.h for version of Xen earlier then 480. - added checking for version 480 to configure. The test repeats all the operation that are required for version < 480 and checks if xengnttab_grant_copy() is implemented. 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
WARNING: multiple messages have this Message-ID (diff)
From: Paulina Szubarczyk <paulinaszubarczyk@gmail.com> To: xen-devel@lists.xenproject.org Cc: sstabellini@kernel.org, wei.liu2@citrix.com, Paulina Szubarczyk <paulinaszubarczyk@gmail.com>, ian.jackson@eu.citrix.com, qemu-devel@nongnu.org, david.vrabel@citrix.com, anthony.perard@citrix.com, roger.pau@citrix.com Subject: [PATCH v4 0/2] qemu-qdisk: Implementation of grant copy operation. Date: Tue, 2 Aug 2016 16:06:28 +0200 [thread overview] Message-ID: <1470146790-6168-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 v3: Interface: - revert to cast from xengnttab_grant_copy_segment_t to ioctl_gntdev_grant_copy. - added compile-time check to compare the libs xengnttab_grant_copy_segment_t with the ioctl structure. The patch relies on Wei patch introducing XENGNTTAB_BUILD_BUG_ON in libs/gnttab. qemu-qdisk: - qemu_memalign/qemu_free is used instead function allocating memory from xc. - removed the get_buffer function instead there is a direct call to qemu_memalign. - moved ioreq_copy for write operation to ioreq_runio_qemu_aio. - added struct xengnttab_grant_copy_segment_t and stub in xen_common.h for version of Xen earlier then 480. - added checking for version 480 to configure. The test repeats all the operation that are required for version < 480 and checks if xengnttab_grant_copy() is implemented. 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 https://lists.xen.org/xen-devel
next reply other threads:[~2016-08-02 14:06 UTC|newest] Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top 2016-08-02 14:06 Paulina Szubarczyk [this message] 2016-08-02 14:06 ` [PATCH v4 0/2] qemu-qdisk: Implementation of grant copy operation Paulina Szubarczyk 2016-08-02 14:06 ` [Qemu-devel] [PATCH v4 1/2] Interface for grant copy operation in libs Paulina Szubarczyk 2016-08-02 14:06 ` Paulina Szubarczyk 2016-08-03 14:36 ` David Vrabel 2016-08-03 14:36 ` [Qemu-devel] [Xen-devel] " David Vrabel 2016-08-04 9:42 ` David Vrabel 2016-08-04 9:42 ` David Vrabel 2016-08-04 9:38 ` Wei Liu 2016-08-04 9:38 ` [Qemu-devel] " Wei Liu 2016-08-04 10:27 ` Paulina Szubarczyk 2016-08-04 10:27 ` Paulina Szubarczyk 2016-08-02 14:06 ` [Qemu-devel] [PATCH v4 2/2] qdisk - hw/block/xen_disk: grant copy implementation Paulina Szubarczyk 2016-08-02 14:06 ` Paulina Szubarczyk 2016-08-08 11:11 ` [Qemu-devel] " Roger Pau Monné 2016-08-08 11:11 ` Roger Pau Monné 2016-08-08 11:34 ` [Qemu-devel] " Paulina Szubarczyk 2016-08-08 11:34 ` Paulina Szubarczyk 2016-08-08 11:44 ` Paulina Szubarczyk 2016-08-08 11:44 ` [Qemu-devel] " Paulina Szubarczyk 2016-08-09 16:56 ` Anthony PERARD 2016-08-09 16:56 ` Anthony PERARD 2016-08-09 17:34 ` [Qemu-devel] " Paulina Szubarczyk 2016-08-09 17:34 ` Paulina Szubarczyk 2016-08-10 10:29 ` [Qemu-devel] " Anthony PERARD 2016-08-10 10:29 ` Anthony PERARD 2016-08-16 6:55 [Qemu-devel] [PATCH v4 0/2] qemu-qdisk: Implementation of grant copy operation 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=1470146790-6168-1-git-send-email-paulinaszubarczyk@gmail.com \ --to=paulinaszubarczyk@gmail.com \ --cc=anthony.perard@citrix.com \ --cc=david.vrabel@citrix.com \ --cc=ian.jackson@eu.citrix.com \ --cc=qemu-devel@nongnu.org \ --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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.