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

[Valentin Vidic]

On Sat, Jan 06, 2018 at 11:17:00PM +0100, Hans van Kranenburg wrote:
> I agree that the upstream default, 32 is quite low. This is indeed a
> configuration issue. I myself ran into this years ago with a growing
> number of domUs and network interfaces in use. We have been using
> gnttab_max_nr_frames=128 for a long time already instead.
> 
> I was tempted to reassign src:xen, but in the meantime, this option has
> already been removed again, so this bug does not apply to unstable
> (well, as soon as we get something new in there) any more (as far as I
> can see quickly now).
> 
> https://xenbits.xen.org/gitweb/?p=xen.git;a=commit;h=18b1be5e324bcbe2f10898b116db641d404b3d30

It does not seem to be removed but increased the default from 32 to 64?

> Including a better default for gnttab_max_nr_frames in the grub config
> in the debian xen package in stable sounds reasonable from a best
> practices point of view.
> 
> But, I would be interested in learning more about the relation with
> block mq although. Does using newer linux kernels (like from
> stretch-backports) for the domU always put a bigger strain on this? Or,
> is it just related to the overall number of network devices and block
> devices you are adding to your domUs in your specific own situation, and
> did you just trip over the default limit?

After upgrading the domU and dom0 from jessie to stretch on a big postgresql
database server (50 VCPUs, 200GB RAM) it starting freezing very soon
after boot as posted there here:

  https://lists.xen.org/archives/html/xen-users/2017-07/msg00057.html

It did not have these problems while running jessie versions of the
hypervisor and the kernels.  The problem seems to be related to the
number of CPUs used, as smaller domUs with a few VCPUs did not hang
like this.  Could it be that large number of VCPUs -> more queues in
Xen mq driver -> faster exhaustion of allocated pages?

-- 
Valentin