From patchwork Wed Aug 16 16:46:11 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dario Faggioli X-Patchwork-Id: 9904157 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id AC17C600CA for ; Wed, 16 Aug 2017 16:48:23 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 9DD4528A1B for ; Wed, 16 Aug 2017 16:48:23 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 92BBE28A4C; Wed, 16 Aug 2017 16:48:23 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-3.6 required=2.0 tests=BAYES_00,DKIM_SIGNED, RCVD_IN_DNSWL_MED,RCVD_IN_SORBS_SPAM,T_DKIM_INVALID autolearn=ham version=3.3.1 Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 29DC028A1B for ; Wed, 16 Aug 2017 16:48:23 +0000 (UTC) Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di1SS-0002Ck-Qa; Wed, 16 Aug 2017 16:46:16 +0000 Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1di1SR-0002C1-Jz for xen-devel@lists.xenproject.org; Wed, 16 Aug 2017 16:46:15 +0000 Received: from [85.158.143.35] by server-10.bemta-6.messagelabs.com id 10/02-18185-7D674995; Wed, 16 Aug 2017 16:46:15 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBIsWRWlGSWpSXmKPExsVyMbThsO61sim RBmv/8Vt83zKZyYHR4/CHKywBjFGsmXlJ+RUJrBnvlpxkL1gjUXGoew1bA2OnSBcjF4eQwAxG iV3t81i7GDk5WATWsErcbdAESUgIXGKVmHpzDhtIQkIgTuLZiafMEHalxMTVnxhBbCEBFYmb2 1cxQUz6wShxa8IhFpCEsICexJGjP9ghbF+JhosbwOJsAgYSb3bsBdsmIqAkcW/VZCYQm1ngCZ PEyqeMEFeoSvy/tBWshlfAR2LZgY9gNifQnIUPLrNALPaRONizF6xeVEBOYuXlFqh6QYmTM58 A1XAAzdSUWL9LH2K8vMT2t3OYJzCKzEJSNQuhahaSqgWMzKsYNYpTi8pSi3SNDPSSijLTM0py EzNzdA0NzPRyU4uLE9NTcxKTivWS83M3MQLDnwEIdjD+WhZwiFGSg0lJlNcrf0qkEF9SfkplR mJxRnxRaU5q8SFGGQ4OJQlemVKgnGBRanpqRVpmDjASYdISHDxKIrzzS4DSvMUFibnFmekQqV OMxhxXrqz7wsQx5cD2L0xCLHn5ealS4rw6IJMEQEozSvPgBsESxCVGWSlhXkag04R4ClKLcjN LUOVfMYpzMCoJ814CmcKTmVcCt+8V0ClMQKdcaZ8EckpJIkJKqoExOsqi1ipe+baGTeWHmJ+e 3rciTnuWHBesNfE4Wv+U/0yehsK67HDj2rdbHGbtmF81+62w7c+pkz2Zrxayn5y1JYkl6tDTe XPkpXSNN3CXXWBWc8qaydDDyXnz/U4zuUPVspIO/4wafCVZ71UEOB7+/knl9IL1Ow0My55VP7 93UPaLxOaPrI+UWIozEg21mIuKEwEu7jUECwMAAA== X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-14.tower-21.messagelabs.com!1502901974!71554254!1 X-Originating-IP: [209.85.128.195] X-SpamReason: No, hits=0.0 required=7.0 tests= X-StarScan-Received: X-StarScan-Version: 9.4.45; banners=-,-,- X-VirusChecked: Checked Received: (qmail 38702 invoked from network); 16 Aug 2017 16:46:14 -0000 Received: from mail-wr0-f195.google.com (HELO mail-wr0-f195.google.com) (209.85.128.195) by server-14.tower-21.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 16 Aug 2017 16:46:14 -0000 Received: by mail-wr0-f195.google.com with SMTP id x43so4013278wrb.1 for ; Wed, 16 Aug 2017 09:46:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:from:to:cc:date:message-id:in-reply-to:references :user-agent:mime-version:content-transfer-encoding; bh=Pvam74qp6TkHu7+5g2V69pk7MoqakFukVYQovmCChrE=; b=mQBouKoZ/aE2+IZqK33vvLO/tJWp5/8u7pVxsbFn3BzVaLVNq3Lb+P+GE2aVJhUSLp p3j7rs7GwQaV01twts5ac7qKjHqH+HsfMs9ocOYg/R8iR39VpocDsqOW1nlK+ysfOWOJ KeysvrNvzstjss94FqUSDQZ+UysH1tooz5x7Vw+OG7Pp4y8J51gK3aE+IX0n76r4Lv6J Wiuzq023yQNxfPD6Ww7xOYqxnfu1SY/eBRaD3KoDvsWPru9guhv8KKgEAO92TP0vurHs ajY/fURjdmfQUhLuzB+100AQ8fQhXSk3ZHw0sX5fzlFTLOPCA2gomyHat7KwslqNKDrr x2Ew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:from:to:cc:date:message-id :in-reply-to:references:user-agent:mime-version :content-transfer-encoding; bh=Pvam74qp6TkHu7+5g2V69pk7MoqakFukVYQovmCChrE=; b=tkfGLDrhuroDcrwVxlyK03QSUSQOKeS6B04wJtUOGC4FKe8qRGuYifbWVu5tqXnZIw Vianf4c8jpHerSW0dMvcMpVROqcyd1UkKATm3zP4DttD6gEuYkZp88HKdK+Sd9hw9+nl AurqDDB4+bwnKCS/PPxihMPM6Rr2IuCU4Q6uQm15krZdiIOARo0GB7RlISFP2KPgIN74 CEGmysU4RkoKjJ4QyYbYsAt4tv0VDXVVuNd9RRjboLHlt/UK0s922CDGgUkHdgh567IS V4JN4q7OsxQd/09DyyVumjYrWFHwIIluGHBelIO8BW6mcuE/o63qbt4jWUWMgAJmAFFs yT8A== X-Gm-Message-State: AHYfb5gljmzdkr2Vqsf3eLrxO1ZrBIIzIMpb2V7MpzPz+053AA0jqG08 O+scfDWi+GasVw== X-Received: by 10.223.135.38 with SMTP id a35mr1691927wra.78.1502901973887; Wed, 16 Aug 2017 09:46:13 -0700 (PDT) Received: from Solace.fritz.box ([80.66.223.3]) by smtp.gmail.com with ESMTPSA id g17sm1705159wmc.44.2017.08.16.09.46.12 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 16 Aug 2017 09:46:13 -0700 (PDT) From: Dario Faggioli To: xen-devel@lists.xenproject.org Date: Wed, 16 Aug 2017 18:46:11 +0200 Message-ID: <150290197175.24854.13548942505645507079.stgit@Solace.fritz.box> In-Reply-To: <150290125292.24854.17418548557562763544.stgit@Solace.fritz.box> References: <150290125292.24854.17418548557562763544.stgit@Solace.fritz.box> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Cc: Stefano Stabellini , Wei Liu , George Dunlap , Andrew Cooper , Ian Jackson , Tim Deegan , Julien Grall , Jan Beulich Subject: [Xen-devel] [PATCH v2 6/6] xen: try to prevent idle timer from firing too often. X-BeenThere: xen-devel@lists.xen.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" X-Virus-Scanned: ClamAV using ClamSMTP Idea is: the more CPUs are still active in a grace period, the more we can wait to check whether it's time to invoke the callbacks (on those CPUs that have already quiesced, are idle, and have callbacks queued). What we're trying to avoid is one of those idle CPUs to wake up, only to discover that the grace period is still running, and that it hence could have be slept longer (saving more power). This patch implements an heuristic aimed at achieving that, at the price of having to call cpumask_weight() on the 'entering idle' path, on CPUs with queued callbacks. Of course, we, at the same time, don't want to delay recognising that we can invoke the callbacks for too much, so we also set a maximum. Signed-off-by: Dario Faggioli --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Tim Deegan Cc: Wei Liu Cc: Julien Grall --- xen/common/rcupdate.c | 18 ++++++++++++++---- 1 file changed, 14 insertions(+), 4 deletions(-) diff --git a/xen/common/rcupdate.c b/xen/common/rcupdate.c index e27bfed..b9ae6cc 100644 --- a/xen/common/rcupdate.c +++ b/xen/common/rcupdate.c @@ -110,10 +110,17 @@ struct rcu_data { * About how far in the future the timer should be programmed each time, * it's hard to tell (guess!!). Since this mimics Linux's periodic timer * tick, take values used there as an indication. In Linux 2.6.21, tick - * period can be 10ms, 4ms, 3.33ms or 1ms. Let's use 10ms, to enable - * at least some power saving on the CPU that is going idle. + * period can be 10ms, 4ms, 3.33ms or 1ms. + * + * That being said, we can assume that, the more CPUs are still active in + * the current grace period, the longer it will take for it to come to its + * end. We wait 10ms for each active CPU, as minimizing the wakeups enables + * more effective power saving, on the CPU that has gone idle. But we also + * never wait more than 100ms, to avoid delaying recognising the end of a + * grace period (and the invocation of the callbacks) by too much. */ -#define RCU_IDLE_TIMER_PERIOD MILLISECS(10) +#define RCU_IDLE_TIMER_CPU_DELAY MILLISECS(10) +#define RCU_IDLE_TIMER_PERIOD_MAX MILLISECS(100) static DEFINE_PER_CPU(struct rcu_data, rcu_data); @@ -444,6 +451,7 @@ int rcu_needs_cpu(int cpu) void rcu_idle_timer_start() { struct rcu_data *rdp = &this_cpu(rcu_data); + s_time_t next; /* * Note that we don't check rcu_pending() here. In fact, we don't want @@ -453,7 +461,9 @@ void rcu_idle_timer_start() if (likely(!rdp->curlist)) return; - set_timer(&rdp->idle_timer, NOW() + RCU_IDLE_TIMER_PERIOD); + next = min_t(s_time_t, RCU_IDLE_TIMER_PERIOD_MAX, + cpumask_weight(&rcu_ctrlblk.cpumask) * RCU_IDLE_TIMER_CPU_DELAY); + set_timer(&rdp->idle_timer, NOW() + next); rdp->idle_timer_active = true; }