Interesting qemu/virt-manager bug about the "rotational" attribute on virtio-blk disks

DISCUSSION Stefano Garzarella 3 participants 4 messages Jul 16, 2020 – Jul 23, 2020 1 message not in the archive virtio core

lore

Share & tools

lore

A message that is not in the archive (sent off-list or not yet received): [email protected]

Stefano Garzarella

author

2020-07-16 09:33 UTC #1 lore raw

+Cc Michael, Stefan, [email protected]

Quoted 11 lines · Richard W.M. Jones

https://bugzilla.redhat.com/show_bug.cgi?id=1857515
A virtio-blk disk which is backed by a raw file on an SSD, inside the guest shows rotational = 1.
I assumed that qemu must have a "rotational" property for disks and this would be communicated by virtio to the guest, but qemu and virtio don't seem to have this. Pretty surprising! Is it called something other than "rotational"?

I'm not sure if we need to add this property in QEMU, but in Linux I found these flags (include/linux/blkdev.h) for the block queues:

    #define QUEUE_FLAG_NONROT	6	/* non-rotational device (SSD) */
    #define QUEUE_FLAG_VIRT		QUEUE_FLAG_NONROT /* paravirt device */

xen-blkfront driver is the only one that sets the QUEUE_FLAG_VIRT, should we do the same in the virtio-blk driver regardless of the backend?

Thanks,
Stefano

Stefan Hajnoczi

2020-07-23 10:32 UTC #2 lore raw

Quoted 15 lines · Stefano Garzarella

+Cc Michael, Stefan, [email protected]
Quoted 11 lines · Richard W.M. Jones
https://bugzilla.redhat.com/show_bug.cgi?id=1857515
A virtio-blk disk which is backed by a raw file on an SSD, inside the guest shows rotational = 1.
I assumed that qemu must have a "rotational" property for disks and this would be communicated by virtio to the guest, but qemu and virtio don't seem to have this. Pretty surprising! Is it called something other than "rotational"?

Quoted 8 lines

I'm not sure if we need to add this property in QEMU, but in Linux I found these flags (include/linux/blkdev.h) for the block queues:
    #define QUEUE_FLAG_NONROT	6	/* non-rotational device (SSD) */
    #define QUEUE_FLAG_VIRT		QUEUE_FLAG_NONROT /* paravirt device */
xen-blkfront driver is the only one that sets the QUEUE_FLAG_VIRT, should we do the same in the virtio-blk driver regardless of the backend?

The ability to control this flag would be interesting for performance experiments.

The problem with changing the default is that regressions can be expected. Certain workloads benefit while others regress.

I suggest:
1. Make it controllable so that QUEUE_FLAG_NONROT can be set or clear (not hardcoded to a single value).
2. The device can communicate the optimal setting from the host. The SCSI protocol already conveys this information. Virtio-blk needs a feature bit and possibly config space field.
3. Make it migration-safe. It needs to be configured explicitly so the value doesn't change suddenly across migration.

Stefan

_______________________________________________
Virtualization mailing list
[email protected]
https://lists.linuxfoundation.org/mailman/listinfo/virtualization

Richard W.M. Jones

2020-07-23 10:40 UTC #3 lore raw

Quoted 19 lines · Stefan Hajnoczi

Quoted 18 lines · Stefano Garzarella
+Cc Michael, Stefan, [email protected]
Quoted 11 lines · Richard W.M. Jones
https://bugzilla.redhat.com/show_bug.cgi?id=1857515
A virtio-blk disk which is backed by a raw file on an SSD, inside the guest shows rotational = 1.
I assumed that qemu must have a "rotational" property for disks and this would be communicated by virtio to the guest, but qemu and virtio don't seem to have this. Pretty surprising! Is it called something other than "rotational"?
I'm not sure if we need to add this property in QEMU, but in Linux I found these flags (include/linux/blkdev.h) for the block queues:

Quoted 8 lines

Quoted 5 lines
    #define QUEUE_FLAG_NONROT	6	/* non-rotational device (SSD) */
    #define QUEUE_FLAG_VIRT		QUEUE_FLAG_NONROT /* paravirt device */
xen-blkfront driver is the only one that sets the QUEUE_FLAG_VIRT, should we do the same in the virtio-blk driver regardless of the backend?
The ability to control this flag would be interesting for performance experiments.

I expect there's a pretty strong interaction between this feature and the shared guest io_uring stuff isn't there? I'm not sure if it'll be a positive or negative effect though.

Rich.

Quoted 13 lines

The problem with changing the default is that regressions can be expected. Certain workloads benefit while others regress.
I suggest:
1. Make it controllable so that QUEUE_FLAG_NONROT can be set or clear (not hardcoded to a single value).
2. The device can communicate the optimal setting from the host. The SCSI protocol already conveys this information. Virtio-blk needs a feature bit and possibly config space field.
3. Make it migration-safe. It needs to be configured explicitly so the value doesn't change suddenly across migration.
Stefan

Signature · 5 lines

Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

Stefano Garzarella

author

2020-07-23 11:15 UTC #4 lore raw

Quoted 26 lines · Richard W.M. Jones

Quoted 25 lines · Stefan Hajnoczi
Quoted 23 lines · Stefano Garzarella
+Cc Michael, Stefan, [email protected]
Quoted 11 lines · Richard W.M. Jones
https://bugzilla.redhat.com/show_bug.cgi?id=1857515
A virtio-blk disk which is backed by a raw file on an SSD, inside the guest shows rotational = 1.
I assumed that qemu must have a "rotational" property for disks and this would be communicated by virtio to the guest, but qemu and virtio don't seem to have this. Pretty surprising! Is it called something other than "rotational"?
I'm not sure if we need to add this property in QEMU, but in Linux I found these flags (include/linux/blkdev.h) for the block queues:
    #define QUEUE_FLAG_NONROT	6	/* non-rotational device (SSD) */
    #define QUEUE_FLAG_VIRT		QUEUE_FLAG_NONROT /* paravirt device */
xen-blkfront driver is the only one that sets the QUEUE_FLAG_VIRT, should we do the same in the virtio-blk driver regardless of the backend?

Quoted 6 lines

Quoted 2 lines
The ability to control this flag would be interesting for performance experiments.
I expect there's a pretty strong interaction between this feature and the shared guest io_uring stuff isn't there? I'm not sure if it'll be a positive or negative effect though.

Yeah, it could be! I'll try it out in the next days.

Quoted 14 lines

Rich.
Quoted 11 lines
The problem with changing the default is that regressions can be expected. Certain workloads benefit while others regress.
I suggest:
1. Make it controllable so that QUEUE_FLAG_NONROT can be set or clear (not hardcoded to a single value).
2. The device can communicate the optimal setting from the host. The SCSI protocol already conveys this information. Virtio-blk needs a feature bit and possibly config space field.
3. Make it migration-safe. It needs to be configured explicitly so the value doesn't change suddenly across migration.

Thanks for the suggestions.

I'll spend some time on this.

Stefano