Pkg xen devel - Feb 2018 - Bug#880554: Bug#880554: Bug#880554: Bug#880554: xen domu freezes with kernel linux-image-4.9.0-4-amd64

On 02/27/2018 05:05 PM, Hans van Kranenburg wrote:
> [...]
> 
> ...I doubt if it's useful (priority wise) to keep spending a lot of
time
> on this, since the work is really time consuming.
It is, but it's also an interesting problem.

Idle just started domU starts at nr_frames=6 or 7 in all cases.

Same test as before 64 vcpu, 10 disks, trying to hit as many vcpu/disk
combinations:

1. With new modprobe limits applied:

3.16.51-3+deb8u1 -> nr_frames=25
4.9.30-2+deb9u5  -> nr_frames=24
4.9.51-1         -> nr_frames=25
4.14.13-1~bpo9+1 -> nr_frames=23

2. Rebooting dom0, removing limits:

3.16.51-3+deb8u1 -> nr_frames=25
4.9.30-2+deb9u5  -> nr_frames=25
4.9.51-1         -> nr_frames=24
4.14.13-1~bpo9+1 -> nr_frames=46  <--

Well, there it is.

However, I can not, I repeat, not, see a difference between
4.9.30-2+deb9u5 and 4.9.51-1, the versions used to report with in the
very first message on this bug.

1. If you're running into the problem with a 4.9 stretch domU kernel,
you're likely hitting the limits in the same way that I already also hit
them like 10 years ago, just having quite some of either vcpu, vbd or vif.

2. If you're upgrading a domU to use the stretch-backports kernel,
you're suddenly much more likely to bump into the limit.

So:

For 1. the solution is to change the boot parameter by the user, or to
reconsider patching DEFAULT_MAX_NR_GRANT_FRAMES 32 to something else
(xen/include/xen/grant_table.h) but that would require another rounds of
testing to see if it does what we might think it does. I vote no.

To accommodate 2. the better is to ship the modprobe config for 4.8,
since running stretch-backports is a valid 'normal' use case. I vote
yes.

Ian, up to you to make a final decision.

kthxbye,
Hans