[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
|
