From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike Latimer Subject: freemem-slack and large memory environments Date: Mon, 09 Feb 2015 18:27:54 -0700 Message-ID: <4321015.nah3j6dvJq@mlatimer1.dnsdhcp.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: xen-devel@lists.xen.org List-Id: xen-devel@lists.xenproject.org Hi, While testing commit 2563bca1, I found that libxl_get_free_memory returns 0 until there is more free memory than required for freemem-slack. This means that during the domain creation process, freed memory is first set aside for freemem-slack, then marked as truly free for consumption. On machines with large amounts of memory, freemem-slack can be very high (26GB on a 2TB test machine). If freeing this memory takes more time than allowed during domain startup, domain creation fails with ERROR_NOMEM. (Commit 2563bca1 doesn't help here, as free_memkb remains 0 until freemem-slack is satisfied.) There is already a 15% limit on the size of freemem-slack (commit a39b5bc6), but this does not take into consideration very large memory environments. (26GB is only 1.2% of 2TB), where this limit is not hit. It seems that there are two approaches to resolve this: - Introduce a hard limit on freemem-slack to avoid unnecessarily large reservations - Increase the retry count during domain creation to ensure enough time is set aside for any cycles spent freeing memory for freemem-slack (on the test machine, doubling the retry count to 6 is the minimum required) Which is the best approach (or did I miss something)? Thanks! Mike