qemu-commits
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-commits] [qemu/qemu] 20ff90: iotests: Update 082 expected output


From: Peter Maydell
Subject: [Qemu-commits] [qemu/qemu] 20ff90: iotests: Update 082 expected output
Date: Fri, 12 Jul 2019 08:32:30 -0700

  Branch: refs/heads/master
  Home:   https://github.com/qemu/qemu
  Commit: 20ff903d527b6de4220d5124f083a05e512c3581
      
https://github.com/qemu/qemu/commit/20ff903d527b6de4220d5124f083a05e512c3581
  Author: Eric Blake <address@hidden>
  Date:   2019-07-12 (Fri, 12 Jul 2019)

  Changed paths:
    M tests/qemu-iotests/082.out

  Log Message:
  -----------
  iotests: Update 082 expected output

A recent tweak to the '-o help' output for qemu-img needs to be
reflected into the iotests expected outputs.

Fixes: f7077c98
Reported-by: Kevin Wolf <address@hidden>
Signed-off-by: Eric Blake <address@hidden>
Reviewed-by: John Snow <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>


  Commit: 867eccfed84f96b54f4a432c510a02c2ce03b430
      
https://github.com/qemu/qemu/commit/867eccfed84f96b54f4a432c510a02c2ce03b430
  Author: Maxim Levitsky <address@hidden>
  Date:   2019-07-12 (Fri, 12 Jul 2019)

  Changed paths:
    M block/file-posix.c

  Log Message:
  -----------
  file-posix: Use max transfer length/segment count only for SCSI passthrough

Regular kernel block devices (/dev/sda*, /dev/nvme*, etc) don't have
max segment size/max segment count hardware requirements exposed
to the userspace, but rather the kernel block layer
takes care to split the incoming requests that
violate these requirements.

Allowing the kernel to do the splitting allows qemu to avoid
various overheads that arise otherwise from this.

This is especially visible in nbd server,
exposing as a raw file, a mostly empty qcow2 image over the net.
In this case most of the reads by the remote user
won't even hit the underlying kernel block device,
and therefore most of the  overhead will be in the
nbd traffic which increases significantly with lower max transfer size.

In addition to that even for local block device
access the peformance improves a bit due to less
traffic between qemu and the kernel when large
transfer sizes are used (e.g for image conversion)

More info can be found at:
https://bugzilla.redhat.com/show_bug.cgi?id=1647104

Signed-off-by: Maxim Levitsky <address@hidden>
Reviewed-by: Stefan Hajnoczi <address@hidden>
Reviewed-by: Eric Blake <address@hidden>
Reviewed-by: Pankaj Gupta <address@hidden>
Signed-off-by: Kevin Wolf <address@hidden>


  Commit: 1316b1ddc8a05e418c8134243f8bff8cccbbccb1
      
https://github.com/qemu/qemu/commit/1316b1ddc8a05e418c8134243f8bff8cccbbccb1
  Author: Peter Maydell <address@hidden>
  Date:   2019-07-12 (Fri, 12 Jul 2019)

  Changed paths:
    M block/file-posix.c
    M tests/qemu-iotests/082.out

  Log Message:
  -----------
  Merge remote-tracking branch 'remotes/kevin/tags/for-upstream' into staging

Block layer patches:

- file-posix: Fix max transfer length for non-SCSI-passthrough
- iotests: Fix 082 reference output

# gpg: Signature made Fri 12 Jul 2019 14:49:14 BST
# gpg:                using RSA key 7F09B272C88F2FD6
# gpg: Good signature from "Kevin Wolf <address@hidden>" [full]
# Primary key fingerprint: DC3D EB15 9A9A F95D 3D74  56FE 7F09 B272 C88F 2FD6

* remotes/kevin/tags/for-upstream:
  file-posix: Use max transfer length/segment count only for SCSI passthrough
  iotests: Update 082 expected output

Signed-off-by: Peter Maydell <address@hidden>


Compare: https://github.com/qemu/qemu/compare/a2a9d4adabe3...1316b1ddc8a0



reply via email to

[Prev in Thread] Current Thread [Next in Thread]