Re: [Qemu-devel] [PATCH] 9pfs: add support for IO limits to 9p-local driver
Hi, Your series failed automatic build test. Please find the testing commands and their output below. If you have docker installed, you can probably reproduce it locally. Subject: [Qemu-devel] [PATCH] 9pfs: add support for IO limits to 9p-local driver Type: series Message-id: 1473251980-39805-1-git-send-email-pradeep.jagade...@huawei.com === TEST SCRIPT BEGIN === #!/bin/bash set -e git submodule update --init dtc make J=8 docker-test-quick@centos6 make J=8 docker-test-mingw@fedora === TEST SCRIPT END === Updating 3c8cf5a9c21ff8782164d1def7f44bd888713384 From https://github.com/patchew-project/qemu * [new tag] patchew/1473251980-39805-1-git-send-email-pradeep.jagade...@huawei.com -> patchew/1473251980-39805-1-git-send-email-pradeep.jagade...@huawei.com Switched to a new branch 'test' 87e77af 9pfs: add support for IO limits to 9p-local driver === OUTPUT BEGIN === Submodule 'dtc' (git://git.qemu-project.org/dtc.git) registered for path 'dtc' Cloning into 'dtc'... Submodule path 'dtc': checked out '65cc4d2748a2c2e6f27f1cf39e07a5dbabd80ebf' BUILD centos6 ARCHIVE qemu.tgz ARCHIVE dtc.tgz COPY RUNNER RUN test-quick in centos6 No C++ compiler available; disabling C++ specific optional code Install prefix/tmp/qemu-test/src/tests/docker/install BIOS directory/tmp/qemu-test/src/tests/docker/install/share/qemu binary directory /tmp/qemu-test/src/tests/docker/install/bin library directory /tmp/qemu-test/src/tests/docker/install/lib module directory /tmp/qemu-test/src/tests/docker/install/lib/qemu libexec directory /tmp/qemu-test/src/tests/docker/install/libexec include directory /tmp/qemu-test/src/tests/docker/install/include config directory /tmp/qemu-test/src/tests/docker/install/etc local state directory /tmp/qemu-test/src/tests/docker/install/var Manual directory /tmp/qemu-test/src/tests/docker/install/share/man ELF interp prefix /usr/gnemul/qemu-%M Source path /tmp/qemu-test/src C compilercc Host C compiler cc C++ compiler Objective-C compiler cc ARFLAGS rv CFLAGS-O2 -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -pthread -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -g QEMU_CFLAGS -I/usr/include/pixman-1-fPIE -DPIE -m64 -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -Wstrict-prototypes -Wredundant-decls -Wall -Wundef -Wwrite-strings -Wmissing-prototypes -fno-strict-aliasing -fno-common -Wendif-labels -Wmissing-include-dirs -Wempty-body -Wnested-externs -Wformat-security -Wformat-y2k -Winit-self -Wignored-qualifiers -Wold-style-declaration -Wold-style-definition -Wtype-limits -fstack-protector-all LDFLAGS -Wl,--warn-common -Wl,-z,relro -Wl,-z,now -pie -m64 -g make make install install pythonpython -B smbd /usr/sbin/smbd module supportno host CPU x86_64 host big endian no target list x86_64-softmmu aarch64-softmmu tcg debug enabled no gprof enabled no sparse enabledno strip binariesyes profiler no static build no pixmansystem SDL support yes (1.2.14) GTK support no GTK GL supportno VTE support no TLS priority NORMAL GNUTLS supportno GNUTLS rndno libgcrypt no libgcrypt kdf no nettleno nettle kdfno libtasn1 no curses supportno virgl support no curl support no mingw32 support no Audio drivers oss Block whitelist (rw) Block whitelist (ro) VirtFS supportno VNC support yes VNC SASL support no VNC JPEG support no VNC PNG support no xen support no brlapi supportno bluez supportno Documentation no PIE yes vde support no netmap supportno Linux AIO support no ATTR/XATTR support yes Install blobs yes KVM support yes RDMA support no TCG interpreter no fdt support yes preadv supportyes fdatasync yes madvise yes posix_madvise yes uuid support no libcap-ng support no vhost-net support yes vhost-scsi support yes Trace backendslog spice support no rbd support no xfsctl supportno smartcard support no libusbno usb net redir no OpenGL supportno OpenGL dmabufsno libiscsi support no libnfs supportno build guest agent yes QGA VSS support no QGA w32 disk info no QGA MSI support no seccomp support no coroutine backend ucontext coroutine poolyes GlusterFS support no Archipelago support no gcov gcov gcov enabled no TPM support yes libssh2 support no TPM passthrough yes QOM debugging yes vhdx no lzo support no snappy supportno bzip2 support no NUMA host support no tcmalloc support no jemalloc support no avx2 optimization no GEN x86_64-softmmu/config-devices.mak.tmp GEN aarch64-softmmu/config-devices.mak.tmp GEN config-host.h GEN qemu-options.def GEN qapi-types.h GEN
Re: [Qemu-devel] [PATCH] 9pfs: add support for IO limits to 9p-local driver
On 09/07/2016 07:39 AM, Pradeep wrote:
> Uses throttling APIs to limit I/O bandwidth and number of operations on the
> devices which use 9p-local driver.
>
> Signed-off-by: Pradeep
> fsdev/file-op-9p.h | 3 +
> fsdev/qemu-fsdev-opts.c | 52 +
> hw/9pfs/9p-local.c | 18 -
> hw/9pfs/9p-throttle.c | 199
>
> hw/9pfs/9p-throttle.h | 55 +
> hw/9pfs/9p.c| 7 ++
> hw/9pfs/Makefile.objs | 1 +
> 7 files changed, 333 insertions(+), 2 deletions(-)
> create mode 100644 hw/9pfs/9p-throttle.c
> create mode 100644 hw/9pfs/9p-throttle.h
>
> Hi All,
>
> This adds the support for the 9p-local driver.
> For now this functionality can be enabled only through qemu cli options.
> QMP interface and support to other drivers need further extensions.
> To make it simple for other drivers, the throttle code has been put in
> separate files.
CLI-only extensions mean that we can't use it during hotplug. Are you
sure that blockdev-add won't automatically enable these options, given
that it tries to convert the dictionary passed through QMP back into the
QemuOpts form that matches command line parsing? Also, aren't these
limits very similar to what is already available in the throttle driver?
Why are we repeating them at the 9p driver, instead of putting a
throttle group BDS in the mix?
> +++ b/fsdev/qemu-fsdev-opts.c
> @@ -37,6 +37,58 @@ static QemuOptsList qemu_fsdev_opts = {
> }, {
> .name = "sock_fd",
> .type = QEMU_OPT_NUMBER,
> +}, {
> +.name = "bps",
> +.type = QEMU_OPT_NUMBER,
> +.help = "total bytes burst",
> +}, {
> +.name = "bps_rd",
> +.type = QEMU_OPT_NUMBER,
> +.help = "total bytes read burst",
> +}, {
At the very least, if we must have multiple throttle implementations,
can they at least share code so that we don't forget to update one when
adding another option to the other?
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [Qemu-devel] [PATCH] 9pfs: add support for IO limits to 9p-local driver
On Wed, 7 Sep 2016 16:36:12 -0500
Eric Blake wrote:
> On 09/07/2016 07:39 AM, Pradeep wrote:
> > Uses throttling APIs to limit I/O bandwidth and number of operations on the
> > devices which use 9p-local driver.
> >
> > Signed-off-by: Pradeep
> > fsdev/file-op-9p.h | 3 +
> > fsdev/qemu-fsdev-opts.c | 52 +
> > hw/9pfs/9p-local.c | 18 -
> > hw/9pfs/9p-throttle.c | 199
> >
> > hw/9pfs/9p-throttle.h | 55 +
> > hw/9pfs/9p.c| 7 ++
> > hw/9pfs/Makefile.objs | 1 +
> > 7 files changed, 333 insertions(+), 2 deletions(-)
> > create mode 100644 hw/9pfs/9p-throttle.c
> > create mode 100644 hw/9pfs/9p-throttle.h
> >
> > Hi All,
> >
> > This adds the support for the 9p-local driver.
> > For now this functionality can be enabled only through qemu cli options.
> > QMP interface and support to other drivers need further extensions.
> > To make it simple for other drivers, the throttle code has been put in
> > separate files.
>
> CLI-only extensions mean that we can't use it during hotplug. Are you
> sure that blockdev-add won't automatically enable these options, given
> that it tries to convert the dictionary passed through QMP back into the
> QemuOpts form that matches command line parsing? Also, aren't these
9p-local is fsdev, not blockdev: it has its own QemuOpts and cannot be
passed to blockdev-add (and BTW, there isn't any fsdev-add either).
> limits very similar to what is already available in the throttle driver?
Yes, IIUC this patch tries to implement similar throttling concepts to the
read/write operations in fsdev.
More details on the motivation here:
https://lists.gnu.org/archive/html/qemu-discuss/2016-04/msg00064.html
> Why are we repeating them at the 9p driver, instead of putting a
> throttle group BDS in the mix?
>
Not sure if it is possible to mix fsdev and blockdev... to be honest, I
really don't know how one would achieve that :)
> > +++ b/fsdev/qemu-fsdev-opts.c
> > @@ -37,6 +37,58 @@ static QemuOptsList qemu_fsdev_opts = {
> > }, {
> > .name = "sock_fd",
> > .type = QEMU_OPT_NUMBER,
> > +}, {
> > +.name = "bps",
> > +.type = QEMU_OPT_NUMBER,
> > +.help = "total bytes burst",
> > +}, {
> > +.name = "bps_rd",
> > +.type = QEMU_OPT_NUMBER,
> > +.help = "total bytes read burst",
> > +}, {
>
>
> At the very least, if we must have multiple throttle implementations,
> can they at least share code so that we don't forget to update one when
> adding another option to the other?
>
This is experimental work. If it turns out that fsdev and blockdev
throttling are close enough, I agree that they should probably share
code. But at this point, I guess they should remain distinct.
Cheers.
--
Greg
pgpYDWu88aig9.pgp
Description: OpenPGP digital signature
