Hi Hans,
I can try, but the only system I can really test this is a productive
system, as this 'reliable' shows this issue (and I don't want to crash
it on purpose on a regular basis). Since I set gnttab_max_frame to a
higher value it runs smooth. If you're confident this will work I can
try this in the eventing, when all users logged off.
Best regards,
Chritian
On 23.02.2018 16:18, Hans van Kranenburg wrote:
Hi Valentin, Christian,
Finally getting back to you about the max grant frames issue.
We discussed this with upstream Xen developers, and a different fix was
proposed. I would really appreciate if you could test it and confirm it
also solves the issue. Testing does not involve recompiling the
hypervisor with patches etc.
The deadline for changes for the 9.4 Stretch point release is end next
week, so we aim to get it in then.
The cause of the problem is, like earlier discused, the "blkback
multipage ring" changes a.k.a. "multi-queue xen blk driver" which eats
grant frame resources way too fast.
As shown in the reports, this issue already exists while using the
normal stretch kernel (not only newer backports) in combination with Xen
4.8.
The upstream change we found earlier that doubles the max number to 64
is part of a bigger change that touches more of the inner workings,
making Xen better able to handle the domU kernel behavior. This whole
change is not going to be backported to Xen 4.8.
Can you please test the following, instead of setting the
gnttab_max_frames value:
Create the file
/etc/modprobe.d/xen-blkback-fewer-gnttab-frames
with contents...
# apropos of #880554
# workaround is not required for Xen 4.9 and later
options xen_blkback max_ring_page_order=0
options xen_blkback max_queues=1
...and reboot.
This will cause the domU kernels to behave more in a way that Xen 4.8
can cope with.
Regards,
Hans
