[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] x86/pod: Do not fragment PoD memory allocations

  • To: Elliott Mitchell <ehem+xen@xxxxxxx>
  • From: Roger Pau Monné <roger.pau@xxxxxxxxxx>
  • Date: Mon, 1 Feb 2021 09:15:04 +0100
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=citrix.com; dmarc=pass action=none header.from=citrix.com; dkim=pass header.d=citrix.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GUXDxMsGy43OVp3KsnzbywguZBgojdHyN0MWev1RQQ8=; b=d+nKZ60+lH3Ub2c9+qI3ihLhVLc5nLUE01/VrDQBCqRZ47EkcT6yAP4tjr9v1o+nO/zjAjlKhyiwL2kD15Giepp5v0bih3OGY2hBS9nutONhMqQF17U0hFkd7j1ZGuy9kPVaOX2gk9dzqf/A77s+kb1B3lEz7LGVHJ/doQoDc8n2fIZxOnOhTcMloev6tlIDW4JXCja+o9b9QobSbmivS8XS2Ay20UgrJFMWfllJefEXSj1fHgwLgWOy0JIkmnfjgSpq0capYZYiWoB/OsKqvhafKfn2kUmdXV/JiDdO2Ie8mzaT0cYtRqM7B5aMD7xXZ8b6XKNUUMUWzeHg0hvpaw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cf+rI8hnZPuVph0CR59JthQ8XpPqmy6OXR/1pYZnutOlXX+oaCHPyAkp6mhiSy7DwSJu8q5mYegUDeG3ZHQZ5Sp19pqiJJ19t42ljVB2DngEo9umqaL6rfreuyO6bbn8U6SYNpqvCt7cYSYukE7MNNpg26wv+s/nIFPt3eEnRHcI1quMfrqNqjRQGrwWdfy8fXZLDwjUtQz0GzgvVrWzyngXXOdJL6ULl3z2Gi6zslFPovBy/UMkzMlwC5oZJq4zKLMHVfZ2cuCoL7/GmHZU5lzRG3E9CA0CSr1rWxb7fD2VCk7OQsFnYNGYTPWJTSszXC1IVXhY99t9b+doyNbzpA==
  • Authentication-results: esa2.hc3370-68.iphmx.com; dkim=pass (signature verified) header.i=@citrix.onmicrosoft.com
  • Cc: George Dunlap <George.Dunlap@xxxxxxxxxx>, Jan Beulich <jbeulich@xxxxxxxx>, Wei Liu <wl@xxxxxxx>, "open list:X86" <xen-devel@xxxxxxxxxxxxxxxxxxxx>, Andrew Cooper <Andrew.Cooper3@xxxxxxxxxx>
  • Delivery-date: Mon, 01 Feb 2021 08:15:20 +0000
  • Ironport-sdr: qLTbDWCk7U/Bb+FqsqmbU1k5TRIkuYF+2du4fCPfJXkzuS74kEzgz+CHSqcu5CUOkjSVgjbxhr ghn3oZ0w2tErG0EXap7nQfkvpNaPxsDsG2x7IzKai9qWZNm0ouhhyMNlwvTRT4FbqXx6JWlx6T LWwmf9ncxn++TBtmt9JBkcTtJE3cCbrAZE+Y3wZDoiVFoYBKAhspKbtg9W96Ma4kf5JAAqKaFV /WR9e3kCw2jnhj/TQ/AQmeF846peXU2aff7BvS4NVgSBq7JIzYQvLMISfgtvaMU1tu4YTZm5Le Tkg=
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On Sun, Jan 31, 2021 at 10:13:49AM -0800, Elliott Mitchell wrote:
> On Thu, Jan 28, 2021 at 10:42:27PM +0000, George Dunlap wrote:
> > 
> > > On Jan 28, 2021, at 6:26 PM, Elliott Mitchell <ehem+xen@xxxxxxx> wrote:
> > > type = "hvm"
> > > memory = 1024
> > > maxmem = 1073741824
> > > 
> > > I suspect maxmem > free Xen memory may be sufficient.  The instances I
> > > can be certain of have been maxmem = total host memory *7.
> > 
> > Can you include your Xen version and dom0 command-line?
> > This is on staging-4.14 from a month or two ago (i.e., what I happened to 
> > have on a random test  box), and `dom0_mem=1024M,max:1024M` in my 
> > command-line.  That rune will give dom0 only 1GiB of RAM, but also prevent 
> > it from auto-ballooning down to free up memory for the guest.
> > 
> As this is a server, not a development target, Debian's build of 4.11 is
> in use.  Your domain 0 memory allocation is extremely generous compared
> to mine.  One thing which is on the command-line though is
> "watchdog=true".
> I've got 3 candidates which presently concern me:ble:
> 1> There is a limited range of maxmem values where this occurs.  Perhaps
> 1TB is too high on your machine for the problem to reproduce.  As
> previously stated my sample configuration has maxmem being roughly 7
> times actual machine memory.
> 2> Between issuing the `xl create` command and the machine rebooting a
> few moments of slow response have been observed.  Perhaps the memory
> allocator loop is hogging processor cores long enough for the watchdog to
> trigger?
> 3> Perhaps one of the patches on Debian broke things?  This seems
> unlikely since nearly all of Debian's patches are either strictly for
> packaging or else picks from Xen's main branch, but this is certainly
> possible.

If you have a reliable way to reproduce this, and such error happens
on one of your server boxes, is it impossible for you to connect to
the serial console and get the output of the crash?

I would assume this being a server it must have some kind of serial
console support, even if Serial over LAN.

That way we could remove all the speculation about what has gone

Thanks, Roger.



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.