Using tools such as ionice inside guests
Dear kvm developpers/users,
I just saw that a change has been made in the kernel so the only one scheduler available in guests for virtio-blk is now "none".
Seems introduced by [1].
I tried to used ionice on a 3.16 guest with virtio-blk and in fact it no longer works because cfq is no longer available.
Is there a way to use, inside a guest, a tool like ionice to set different IO priority in guests processes? It's very useful for loering down the performance impact of backups jobs for example.
Paolo Bonzini
maintainerQuoted 6 lines · Emmanuel Lacour
Dear kvm developpers/users,
I just saw that a change has been made in the kernel so the only one scheduler available in guests for virtio-blk is now "none".
Seems introduced by [1].
Not by this one; rather this one:
Quoted 10 lines
I tried to used ionice on a 3.16 guest with virtio-blk and in fact it no longer works because cfq is no longer available.
Is there a way to use, inside a guest, a tool like ionice to set different IO priority in guests processes? It's very useful for loering down the performance impact of backups jobs for example.
Not anymore unfortunately. The effect of this change was not advertised enough, in my opinion. The blk-mq path should have replaced the code used by use_bio=1, but not the code used by use_bio=0.
Thanks,
Paolo
Thanks, it's a bad news for us :(
I will try to play with cgroups io throttling to limit by iops or bytes read, but it'll be a hard limit rather than a priority :(
Do you think there could be back some io priority throttling in not so far future kernels?
Paolo Bonzini
maintainerQuoted 4 lines · Emmanuel Lacour
Thanks, it's a bad news for us :(
I will try to play with cgroups io throttling to limit by iops or bytes read, but it'll be a hard limit rather than a priority :(
That probably won't work either, but you can use io throttling on the host too.
Quoted 2 lines
Do you think there could be back some io priority throttling in not so far future kernels?
I wouldn't oppose a patch to add back the non-mq path, but as far as I know nobody is working on it. It's not hard and I can help if you need guidance.
Adding I/O scheduler support to blk-mq has been promised for at least a year now, but I'm not aware of which kernel release might have the work.
It's not even been submitted to LKML, so I guess it's quite far away.
Thanks,
Paolo
Quoted 14 lines · Paolo Bonzini
Quoted 4 lines · Emmanuel Lacour
Thanks, it's a bad news for us :(
I will try to play with cgroups io throttling to limit by iops or bytes read, but it'll be a hard limit rather than a priority :(
That probably won't work either, but you can use io throttling on the host too.
Quoted 2 lines
Do you think there could be back some io priority throttling in not so far future kernels?
Quoted 7 lines
I wouldn't oppose a patch to add back the non-mq path, but as far as I know nobody is working on it. It's not hard and I can help if you need guidance.
Adding I/O scheduler support to blk-mq has been promised for at least a year now, but I'm not aware of which kernel release might have the work.
It's not even been submitted to LKML, so I guess it's quite far away.
What actually happened to the virtio-blk multiqueue support in QEMU?
Paolo Bonzini
maintainerQuoted 19 lines · Christian Borntraeger
Quoted 18 lines · Paolo Bonzini
Quoted 4 lines · Emmanuel Lacour
Thanks, it's a bad news for us :(
I will try to play with cgroups io throttling to limit by iops or bytes read, but it'll be a hard limit rather than a priority :(
That probably won't work either, but you can use io throttling on the host too.
Quoted 2 lines
Do you think there could be back some io priority throttling in not so far future kernels?
I wouldn't oppose a patch to add back the non-mq path, but as far as I know nobody is working on it. It's not hard and I can help if you need guidance.
Quoted 5 lines
Quoted 3 lines
Adding I/O scheduler support to blk-mq has been promised for at least a year now, but I'm not aware of which kernel release might have the work.
It's not even been submitted to LKML, so I guess it's quite far away.What actually happened to the virtio-blk multiqueue support in QEMU?
The guy who submitted the patch for the "fake" virtio-blk multiqueue (backed by a single iothread) disappeared. "Real" virtio-blk multiqueue is at least 80 patches away (70 of those have been written :)).
However, multiqueue is independent from Emmanuel's problem.
Thanks,
Paolo
Quoted 11 lines · Paolo Bonzini
Quoted 4 lines · Emmanuel Lacour
Thanks, it's a bad news for us :(
I will try to play with cgroups io throttling to limit by iops or bytes read, but it'll be a hard limit rather than a priority :(
That probably won't work either, but you can use io throttling on the host too.
I'll try and let you now if it works. I cannot do this on the host, because it's per processes inside each VMs, not betweeen VMs.
Quoted 11 lines
Quoted 2 lines
Do you think there could be back some io priority throttling in not so far future kernels?
I wouldn't oppose a patch to add back the non-mq path, but as far as I know nobody is working on it. It's not hard and I can help if you need guidance.
Adding I/O scheduler support to blk-mq has been promised for at least a year now, but I'm not aware of which kernel release might have the work.
It's not even been submitted to LKML, so I guess it's quite far away.
Unfortunatly, I'm a sysadmin with too much little dev knowledge :(