From patchwork Thu Jul 27 08:01:31 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Dario Faggioli X-Patchwork-Id: 9866405 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 8069E6038C for ; Thu, 27 Jul 2017 08:03:54 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 7066928780 for ; Thu, 27 Jul 2017 08:03:54 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 62A5928796; Thu, 27 Jul 2017 08:03:54 +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 CC73028780 for ; Thu, 27 Jul 2017 08:03:53 +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 1dadjl-0000JD-E6; Thu, 27 Jul 2017 08:01:37 +0000 Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dadjj-0000I9-I4 for xen-devel@lists.xenproject.org; Thu, 27 Jul 2017 08:01:35 +0000 Received: from [85.158.137.68] by server-13.bemta-3.messagelabs.com id 1F/76-01862-EDD99795; Thu, 27 Jul 2017 08:01:34 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrMIsWRWlGSWpSXmKPExsXiVRvkpHt3bmW kwflb5hbft0xmcmD0OPzhCksAYxRrZl5SfkUCa8aB1W1MBZtEK+79n8PWwNgo2MXIxSEkMINR ouNUKzuIwyKwhlVi8qfbrCCOhMAlVomf7+YxdTFyAjlxEo0P7jFD2BUS28/0s4PYQgIqEje3r 2KCGPWTUWL2rJVsIAlhAT2JI0d/sEPY7hIdt9vBbDYBA4k3O/aygtgiAkoS91ZNBlvALPCESW LlU0YQm0VAVWLh/n8sIDavgKPE7MffwHo5BZwlLp/YwAKx2Eni9K5VYLtEBeQkVl5uYYWoF5Q 4OfMJUA0H0ExNifW79CHGy0tsfzuHeQKjyCwkVbMQqmYhqVrAyLyKUaM4tagstUjXyFIvqSgz PaMkNzEzR9fQwFgvN7W4ODE9NScxqVgvOT93EyMwAuoZGBh3MDbt9TvEKMnBpCTKO8m0IlKIL yk/pTIjsTgjvqg0J7X4EKMMB4eSBO/lOZWRQoJFqempFWmZOcBYhElLcPAoifD+mg2U5i0uSM wtzkyHSJ1i1OWYdGD7FyYhlrz8vFQpcd55IDMEQIoySvPgRsDSwiVGWSlhXkYGBgYhnoLUotz MElT5V4ziHIxKwrz7QKbwZOaVwG16BXQEE9ARE5vAjihJREhJNTBq7N2TGtRf8Xv1jZaZ89pY 5qW/Wd3gdyLTeap4+Ksz7grrlA/+EWPY7Z74K0jrVuWWnalzXRVMOb5Zy03tT2rffVG4Wjt6B U+xWsusJ4yrJdsnzjiyS3TNA1OJvDPOa1a46t/x7NdYunrn7wDFz+drOZuu8waUz2pg0WZ1y9 S/7LPi+KteHTklluKMREMt5qLiRADqj2UVBgMAAA== X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-16.tower-31.messagelabs.com!1501142493!99731040!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.25; banners=-,-,- X-VirusChecked: Checked Received: (qmail 29052 invoked from network); 27 Jul 2017 08:01:33 -0000 Received: from mail-wm0-f66.google.com (HELO mail-wm0-f66.google.com) (74.125.82.66) by server-16.tower-31.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 27 Jul 2017 08:01:33 -0000 Received: by mail-wm0-f66.google.com with SMTP id t138so3800264wmt.4 for ; Thu, 27 Jul 2017 01:01:33 -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=xk2IqqNYBUmUHGnVYbbnJA1dx9v2wC0LeLDog6BV5bQ=; b=cw0ttDLmUI0e1w6CP19vpO8FEBsaKLpfEeBBSI5GjQEB38mCCoOuXoPpdWDehlbj3B MRmVWYHx30NS4osTuGD10BFmbYh4BIzZQG7yu9pDXCU6aNmf5szUhPiKhGt6/7QLt6sW VnQypweoaIMx9CuwzW8SoE7An1Qi1anpE5duzeLhD5eIuIC38FJuCBuCaYsIiDqHcCGe FclJIpxjvvMtBVO8lysCdQmPD36Lg+TcCYz3+vSaIkh2qTE4V45SxzXLYFtdEgAmij36 f4UdXarSwxE2Itr/EeJpQxVSiRPqhjvd8X2gsxS8UM8t0zlHP2iZgF9CKYV91Bar198u Fa9Q== 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=xk2IqqNYBUmUHGnVYbbnJA1dx9v2wC0LeLDog6BV5bQ=; b=d6AxEzI9OK9dVr9ahaDDw50Fh2iNAWBG9L/D7jVWeQ9Kor+pWTfro+Ji8Read/5iWM 2s/LgpmsnKempRi1ODvrUe7QmYCUJ6GDz1vZjDOwhxpk86RXEz//BWUyPTUNyFl2btuh 4ypihZsXoOaj9TZ5gjTtZKp17krQWVaRQG6qtqvWGmYlIN/Vntw177xVuHh5mxQMmdvV S5mqwN6aM10F+8cTh50pILafuSvQZhKE6F/psBVC0eYvCLtb0SnEU6Npp2BiVi73AY1T ZzuLje36BgvJ3pnLbJxdZvGaMpn6mUo+GBIUdUXLPgQ6n0hoxmt8QTmOBBTPTF7YfgW0 5cGg== X-Gm-Message-State: AIVw111hdbdzb85J3/XZSncFHHKY1RgjdQfjjSB2sUD1tUft540i6FYP pAd1+/3y4He1J/Pd X-Received: by 10.28.180.69 with SMTP id d66mr2475394wmf.56.1501142493485; Thu, 27 Jul 2017 01:01:33 -0700 (PDT) Received: from [192.168.0.31] ([80.66.223.212]) by smtp.gmail.com with ESMTPSA id y12sm35398255wrb.39.2017.07.27.01.01.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Jul 2017 01:01:32 -0700 (PDT) From: Dario Faggioli To: xen-devel@lists.xenproject.org Date: Thu, 27 Jul 2017 10:01:31 +0200 Message-ID: <150114249133.22910.6287911784333237605.stgit@Solace> In-Reply-To: <150114201043.22910.12807057883146318803.stgit@Solace> References: <150114201043.22910.12807057883146318803.stgit@Solace> 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 4/5] xen: RCU: don't let a CPU with a callback go idle. 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 If a CPU has a callback queued, it must be ready to invoke it, as soon as all the other CPUs involved in the grace period has gone through a quiescent state. But if we let such CPU go idle, we can't really tell when (if!) it will realize that it is actually time to invoke the callback. To solve this problem, a CPU that has a callback queued (and has already gone through a quiescent state itself) will stay online, until the grace period ends, and the callback can be invoked. This is similar to what Linux does, and is the second and last step for fixing the overly long (or infinite!) grace periods. The problem, though, is that, within Linux, we have the tick, so, all that is necessary is to not stop the tick for the CPU (even if it has gone idle). In Xen, there's no tick, so we must avoid for the CPU to go idle entirely, and let it spin on rcu_pending(), consuming power and causing overhead. In this commit, we implement the above, using rcu_needs_cpu(), in a way similar to how it is used in Linux. This it correct, useful and not wasteful for CPUs that participate in grace period, but have not a callback queued. For the ones that has callbacks, an optimization that avoids having to spin is introduced in next commit. Signed-off-by: Dario Faggioli Reviewed-by: Jan Beulich --- Cc: Andrew Cooper Cc: George Dunlap Cc: Ian Jackson Cc: Jan Beulich Cc: Konrad Rzeszutek Wilk Cc: Stefano Stabellini Cc: Julien Grall Cc: Tim Deegan Cc: Wei Liu --- xen/include/xen/sched.h | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/xen/include/xen/sched.h b/xen/include/xen/sched.h index 6673b27..df93a86 100644 --- a/xen/include/xen/sched.h +++ b/xen/include/xen/sched.h @@ -842,7 +842,8 @@ uint64_t get_cpu_idle_time(unsigned int cpu); /* * Used by idle loop to decide whether there is work to do: - * (1) Run softirqs; or (2) Play dead; or (3) Run tasklets. + * (1) Deal with RCU; (2) or run softirqs; or (3) Play dead; + * or (4) Run tasklets. * * About (3), if a tasklet is enqueued, it will be scheduled * really really soon, and hence it's pointless to try to @@ -850,7 +851,8 @@ uint64_t get_cpu_idle_time(unsigned int cpu); * the tasklet_work_to_do() helper). */ #define cpu_is_haltable(cpu) \ - (!softirq_pending(cpu) && \ + (!rcu_needs_cpu(cpu) && \ + !softirq_pending(cpu) && \ cpu_online(cpu) && \ !per_cpu(tasklet_work_to_do, cpu))