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

"failed to free memory for the domain" from "xl create"


  • To: Ian Jackson <iwj@xxxxxxxxxxxxxx>, Wei Liu <wl@xxxxxxx>, Anthony Perard <anthony.perard@xxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Thu, 19 Aug 2021 16:09:36 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.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=PGu7DKlvwxRpP226AGwTWWbu50CFyIs2SldBfi3CJ2M=; b=Cr5s0FvbtNPhx1/iKJFhja8BuyyaPuXlKDBzJr0mTmWCogm2u19Y5L1oJvfgnNIlQT3txpRdWQxq3xThbUA4jE/WUI0LaYG+H08K4N/G0zkIcSpZR/ANtnc4MBoX9RoLNg03mat5pOBiePjfdH065F5yxn48+mS0mC6UDXnrPqI1WKTDYW77/Q/A7pmVkw7CGRylmeE1AQAzji892EMUYw6LWpO7dGX6645LxIUEsVieEJRGKBwjLtQSYye0uR8Wqeggw92nNie8C1Z32q/l28SztBoU+ZZPeWcZt9n0CGhGG9PVqDxbchnO93I/cSFb4DJK65vNrG2YgyyE/HwbjA==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=bwiUiJ4WG9cGzHKPhmYxi+aekZ0UWSWG8CM88NQfV6VzIf7xPGWclHfejm/+wNi4ciMGL6RgHicJjdg98DsXVsfSGtJW7pzBvVLdw3iBg+dQAGhTj+Mv7rIHObNBa1daAgoTVRiX4WT0ehbNWP8PvtWAnQWBDBImKx20ZhX5IXB9am9T7J7T30TCt9F5/K6XmumGND13bWwqED76Dr4mcKFEgoEgBzM/rL1NjF0m7s8Xtj/QS/OJ+S02b3u3iTY3eMnVlVVKF6Zq28E9tNydNdWiXrGUPHmQNXGj4/KiX+iCnGg2tG4/4478CFBF5pmEy2onU8dtlMWiHmdmurt1Ig==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: "xen-devel@xxxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxxx>
  • Delivery-date: Thu, 19 Aug 2021 14:09:57 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

Hello,

besides there not having been any indication what has gone wrong
(if anything in the first place), I wonder in how far the operation
of freemem() / libxl_wait_for_memory_target() is fully suitable for
all possible scenarios. I did create the guest in question on a
Dom0 running in strict mode on large IOMMU page mappings (as far as
they didn't get shattered by that point). If we consider the case
of Dom0 ballooning out a page that was mapped by a 1G mapping, then
the shattering of the 1G page as well as one of the resulting 2M
pages would result in _one less_ free pages in the end: The
ballooned out page was freed at the price of the allocation of two
pages to become page table ones. This looks to undermine the
"forward progress" determination, which I consider fragile anyway
as long as other parallel operations potentially consuming memory
aren't locked out.

Does one of you have thoughts towards possible improvements here?

Thanks, Jan




 


Rackspace

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