From patchwork Fri Jan 15 13:30:45 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Vitaly Kuznetsov X-Patchwork-Id: 8040741 Return-Path: X-Original-To: patchwork-xen-devel@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork1.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork1.web.kernel.org (Postfix) with ESMTP id EB89D9FE73 for ; Fri, 15 Jan 2016 13:33:49 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id 179D02040F for ; Fri, 15 Jan 2016 13:33:49 +0000 (UTC) Received: from lists.xen.org (lists.xenproject.org [50.57.142.19]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id 139EB2041A for ; Fri, 15 Jan 2016 13:33:46 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xen.org) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aK4T4-00028T-2d; Fri, 15 Jan 2016 13:31:06 +0000 Received: from mail6.bemta14.messagelabs.com ([193.109.254.103]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aK4T2-00027d-CL for xen-devel@lists.xenproject.org; Fri, 15 Jan 2016 13:31:04 +0000 Received: from [193.109.254.147] by server-2.bemta-14.messagelabs.com id 50/56-12889-794F8965; Fri, 15 Jan 2016 13:31:03 +0000 X-Env-Sender: vkuznets@redhat.com X-Msg-Ref: server-6.tower-27.messagelabs.com!1452864661!17172569!1 X-Originating-IP: [209.132.183.28] X-SpamReason: No, hits=0.0 required=7.0 tests=sa_preprocessor: VHJ1c3RlZCBJUDogMjA5LjEzMi4xODMuMjggPT4gNTQwNjQ=\n X-StarScan-Received: X-StarScan-Version: 7.35.1; banners=-,-,- X-VirusChecked: Checked Received: (qmail 56196 invoked from network); 15 Jan 2016 13:31:02 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by server-6.tower-27.messagelabs.com with DHE-RSA-AES256-GCM-SHA384 encrypted SMTP; 15 Jan 2016 13:31:02 -0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) by mx1.redhat.com (Postfix) with ESMTPS id D93BCC0B60E7; Fri, 15 Jan 2016 13:31:00 +0000 (UTC) Received: from vitty.brq.redhat.com (vitty.brq.redhat.com [10.34.26.3]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u0FDUkJa006434; Fri, 15 Jan 2016 08:30:56 -0500 From: Vitaly Kuznetsov To: linux-mm@kvack.org Date: Fri, 15 Jan 2016 14:30:45 +0100 Message-Id: <1452864645-27778-3-git-send-email-vkuznets@redhat.com> In-Reply-To: <1452864645-27778-1-git-send-email-vkuznets@redhat.com> References: <1452864645-27778-1-git-send-email-vkuznets@redhat.com> X-Scanned-By: MIMEDefang 2.68 on 10.5.11.23 Cc: Naoya Horiguchi , linux-doc@vger.kernel.org, Jonathan Corbet , Boris Ostrovsky , Greg Kroah-Hartman , Daniel Kiper , Kay Sievers , linux-kernel@vger.kernel.org, Tang Chen , xen-devel@lists.xenproject.org, Igor Mammedov , David Vrabel , David Rientjes , Xishi Qiu , Dan Williams , "K. Y. Srinivasan" , Mel Gorman , Andrew Morton Subject: [Xen-devel] [PATCH v6 2/2] xen_balloon: support memory auto onlining policy X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_MED, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP Add support for the newly added kernel memory auto onlining policy to Xen ballon driver. Suggested-by: Daniel Kiper Reviewed-by: Daniel Kiper Acked-by: David Vrabel Signed-off-by: Vitaly Kuznetsov --- Changes since v5: - Change the last 'domU' -> 'target domain' in Kconfig [Daniel Kiper] --- drivers/xen/Kconfig | 23 +++++++++++++++-------- drivers/xen/balloon.c | 11 ++++++++++- 2 files changed, 25 insertions(+), 9 deletions(-) diff --git a/drivers/xen/Kconfig b/drivers/xen/Kconfig index 73708ac..979a8317 100644 --- a/drivers/xen/Kconfig +++ b/drivers/xen/Kconfig @@ -37,23 +37,30 @@ config XEN_BALLOON_MEMORY_HOTPLUG Memory could be hotplugged in following steps: - 1) dom0: xl mem-max + 1) target domain: ensure that memory auto online policy is in + effect by checking /sys/devices/system/memory/auto_online_blocks + file (should be 'online'). + + 2) control domain: xl mem-max where is >= requested memory size, - 2) dom0: xl mem-set + 3) control domain: xl mem-set where is requested memory size; alternatively memory could be added by writing proper value to /sys/devices/system/xen_memory/xen_memory0/target or - /sys/devices/system/xen_memory/xen_memory0/target_kb on dumU, + /sys/devices/system/xen_memory/xen_memory0/target_kb on the + target domain. - 3) domU: for i in /sys/devices/system/memory/memory*/state; do \ - [ "`cat "$i"`" = offline ] && echo online > "$i"; done + Alternatively, if memory auto onlining was not requested at step 1 + the newly added memory can be manually onlined in the target domain + by doing the following: - Memory could be onlined automatically on domU by adding following line to udev rules: + for i in /sys/devices/system/memory/memory*/state; do \ + [ "`cat "$i"`" = offline ] && echo online > "$i"; done - SUBSYSTEM=="memory", ACTION=="add", RUN+="/bin/sh -c '[ -f /sys$devpath/state ] && echo online > /sys$devpath/state'" + or by adding the following line to udev rules: - In that case step 3 should be omitted. + SUBSYSTEM=="memory", ACTION=="add", RUN+="/bin/sh -c '[ -f /sys$devpath/state ] && echo online > /sys$devpath/state'" config XEN_BALLOON_MEMORY_HOTPLUG_LIMIT int "Hotplugged memory limit (in GiB) for a PV guest" diff --git a/drivers/xen/balloon.c b/drivers/xen/balloon.c index 890c3b5..f8cca0c 100644 --- a/drivers/xen/balloon.c +++ b/drivers/xen/balloon.c @@ -338,7 +338,16 @@ static enum bp_state reserve_additional_memory(void) } #endif - rc = add_memory_resource(nid, resource, false); + /* + * add_memory_resource() will call online_pages() which in its turn + * will call xen_online_page() callback causing deadlock if we don't + * release balloon_mutex here. Unlocking here is safe because the + * callers drop the mutex before trying again. + */ + mutex_unlock(&balloon_mutex); + rc = add_memory_resource(nid, resource, memhp_auto_online); + mutex_lock(&balloon_mutex); + if (rc) { pr_warn("Cannot add additional memory (%i)\n", rc); goto err;