From patchwork Fri Aug 18 18:04:45 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dario Faggioli X-Patchwork-Id: 9909703 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 36ECB60385 for ; Fri, 18 Aug 2017 18:06:55 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 2B93528CFF for ; Fri, 18 Aug 2017 18:06:55 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 1DA4B28D1D; Fri, 18 Aug 2017 18:06:55 +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 A544428CFF for ; Fri, 18 Aug 2017 18:06:54 +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 1dildb-0002P6-6n; Fri, 18 Aug 2017 18:04:51 +0000 Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dildZ-0002O7-C1 for xen-devel@lists.xenproject.org; Fri, 18 Aug 2017 18:04:49 +0000 Received: from [85.158.139.211] by server-1.bemta-5.messagelabs.com id 73/9A-01993-04C27995; Fri, 18 Aug 2017 18:04:48 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrAIsWRWlGSWpSXmKPExsXiVRvkpGuvMz3 S4Ps8K4vvWyYzOTB6HP5whSWAMYo1My8pvyKBNePzVK2CNRIV/x4/ZG5g7BTpYuTiEBKYxijR 2nWYFcRhEVjDKtF5ciKYIyFwiVViTstD5i5GDiAnTmLCApUuRk4gs1Ji9aSLTCC2kICKxM3tq 5ggJn1nlJj+4yhYQlhAT+LI0R/sELavxK+f/WA2m4CBxJsde1lBbBEBJYl7qyaD1TMLPGGSWP mUEcRmEVCVmPjvFTOIzSvgI3Hi7HE2EJsTyH5x8QQrxGJviXe/V7CA2KICchIrL7ewQtQLSpy c+YQF5GZmAU2J9bv0IcbLS2x/O4d5AqPILCRVsxCqZiGpWsDIvIpRvTi1qCy1SNdML6koMz2j JDcxM0fX0MBULze1uDgxPTUnMalYLzk/dxMjMPQZgGAH49QG50OMkhxMSqK8v2dNiRTiS8pPq cxILM6ILyrNSS0+xCjDwaEkwculPT1SSLAoNT21Ii0zBxiFMGkJDh4lEd4VWkBp3uKCxNzizH SI1ClGXY5JB7Z/YRJiycvPS5US52UHmSEAUpRRmgc3ApYQLjHKSgnzMgIdJcRTkFqUm1mCKv+ KUZyDUUmY9y/IKp7MvBK4Ta+AjmACOsKwdRrIESWJCCmpBsaJWVq5/Y2Xjv0IbOXWbH93/upE 8cxX6UtsOe5OWtHZxWwd2F4XZqawju3IjUcv/WQs7qmsrPxdN0tG/rK38n+nTWtn3Mx/m+1gt Ft/vqOXhejqhwfv/ooKkzIQTeRoj6hSuhK8YUmvZQMDz3qOzXsWa/1p6uW6yNlrHd29JNEyRq 3FzVX8sBJLcUaioRZzUXEiAGOnKmoDAwAA X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-2.tower-206.messagelabs.com!1503079487!87290457!1 X-Originating-IP: [74.125.82.66] 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 47898 invoked from network); 18 Aug 2017 18:04:47 -0000 Received: from mail-wm0-f66.google.com (HELO mail-wm0-f66.google.com) (74.125.82.66) by server-2.tower-206.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 18 Aug 2017 18:04:47 -0000 Received: by mail-wm0-f66.google.com with SMTP id c14so757219wmh.1 for ; Fri, 18 Aug 2017 11:04:47 -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=0ec//mt/y3KHXuylG92JSebQtgdKMucwGNKh5VD2me8=; b=rLB5eaJl+7khBYLh37r5JRLYKuNmJDGqLIHumSLEbMqkGb8n29mF3NflBjaEMsvCgc opWHVBJf5UP/M0zUEB5LnvFZaLJ2HOocViHzw5oWVa/rLOyc8qQ/31BwflauBWLgbVM2 tGnPl/Ef/wCZzoIyXyW+ip3C7YHubxCqb9321kiu8qmWjqjYf2DqNN+NVMsX/fzTbXlT Hbwgsef21T4nwgqhKaTJDo/t0t6WB7PSoUv9MRFR3SlcVOnI1poX5ddrIeXucGgZyLgt vywfiJf8FSVbbSYT8iB//a7D9RywthWdKeWE3xOhbzNQu0PpUkS693LaOu13zkEPKsP2 8KTA== 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=0ec//mt/y3KHXuylG92JSebQtgdKMucwGNKh5VD2me8=; b=GumMyA9NdrjsxBthD2xaXA0k7xqnSwGcBaWBNTspKgU0ezYRON+flrEcXFDqc2Qvtf /okuZ6/5KF1hxg2B6jmzTgHT8wbk4+DArdxQqWhJ0YzMqLoCOU4Qcp/zR56h9H88SErC h5RidY12dplkMiG1A8fofOe8Q3xEDGRHLIIdT914a5OP1S0dFVpmK5HEV3JWK2sDiNW4 ijXWWuyZF7oFUJtiq8YPQbJqjNZsBOg/U7ZupzWJCZFI/eFBs2Q/I2E9EXthweYan5fD 8vBq13tBa6yRBEGk4BGQihGCypcCiD+I/cAeprKzW8HHneL67cFlvOguJHafUfK8mwno 4Faw== X-Gm-Message-State: AHYfb5hPIemudhHgCiD8RkOjIbmlEd9LXAMMtebF4v9ooZhgnuDmAIuG /3+BCyef0skKrg== X-Received: by 10.28.93.138 with SMTP id r132mr2253738wmb.24.1503079487586; Fri, 18 Aug 2017 11:04:47 -0700 (PDT) Received: from Solace.fritz.box ([80.66.223.3]) by smtp.gmail.com with ESMTPSA id d10sm1666429wmh.4.2017.08.18.11.04.45 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 18 Aug 2017 11:04:46 -0700 (PDT) From: Dario Faggioli To: xen-devel@lists.xenproject.org Date: Fri, 18 Aug 2017 20:04:45 +0200 Message-ID: <150307948527.29525.18126889783757078160.stgit@Solace.fritz.box> In-Reply-To: <150307710991.29525.3681195976643263117.stgit@Solace.fritz.box> References: <150307710991.29525.3681195976643263117.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 v3 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 871936f..5a3cb1d 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; }