From patchwork Fri Apr 7 16:56: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: 9669945 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 577EC602A0 for ; Fri, 7 Apr 2017 16:58:49 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 48380285C5 for ; Fri, 7 Apr 2017 16:58:49 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 3CF962861E; Fri, 7 Apr 2017 16:58:49 +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 CD401285C5 for ; Fri, 7 Apr 2017 16:58:48 +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 1cwXBr-0001bQ-QS; Fri, 07 Apr 2017 16:56:51 +0000 Received: from mail6.bemta6.messagelabs.com ([193.109.254.103]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwXBp-0001aT-KJ for xen-devel@lists.xenproject.org; Fri, 07 Apr 2017 16:56:49 +0000 Received: from [85.158.143.35] by server-9.bemta-6.messagelabs.com id DD/E8-03420-0D4C7E85; Fri, 07 Apr 2017 16:56:48 +0000 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRWlGSWpSXmKPExsXiVRvkonvhyPM Ig3O93Bbft0xmcmD0OPzhCksAYxRrZl5SfkUCa8anhytYCxoVKrqv3mFtYFwp0cXIxSEkMJ1R 4v3xH0wgDovAGlaJlYcnMII4EgKXWCVmXHvE3sXICeTESTz4c5EJwq6Q6NvwGCwuJKAicXP7K iYI+zejxMt7iiC2sICexJGjP9ghbBeJlzOOg9lsAgYSb3bsZQWxRQSUJO6tmgzWyywQJXFmeT MziM0ioCoxs6+VEcTmFfCSWPx/L1gvp4CPxLNTs6B2eUusOz8HLC4qICex8nILK0S9oMTJmU9 Yuhg5gGZqSqzfpQ8xXl5i+9s5zBMYRWYhqZqFUDULSdUCRuZVjBrFqUVlqUW6RpZ6SUWZ6Rkl uYmZObqGBmZ6uanFxYnpqTmJScV6yfm5mxiB4c8ABDsYDywKPMQoycGkJMqr4PMkQogvKT+lM iOxOCO+qDQntfgQowYHh8CEs3OnM0mx5OXnpSpJ8Codfh4hJFiUmp5akZaZA4xQmFIJDh4lEV 51kDRvcUFibnFmOkTqFKMux6OVP94zCYHNkBLnrQApEgApyijNgxsBSxaXGGWlhHkZgQ4U4il ILcrNLEGVf8UozsGoJMybBjKFJzOvBG7TK6AjmICO8Ln1FOSIkkSElFQDY+Oin9/b7wTPu65Y 6bl6n6/Fop3yc5RlW2tuet1JK5vGPjl7jfGpY3tmMq/Y8fXkq+D58+sUvb61+NX+4inYPHGt3 G6TNOOzP5kecmh7+5hs+JESM+2gQLrzn5mBL/cF+jJsXOh1jHfdh2Vr7lfaTQuKS11/fkO9TP whkZ+nTRf3zpkz19hV/IISS3FGoqEWc1FxIgD2L9+3EQMAAA== X-Env-Sender: raistlin.df@gmail.com X-Msg-Ref: server-13.tower-21.messagelabs.com!1491584208!56916763!1 X-Originating-IP: [74.125.82.68] X-SpamReason: No, hits=0.5 required=7.0 tests=BODY_RANDOM_LONG X-StarScan-Received: X-StarScan-Version: 9.4.12; banners=-,-,- X-VirusChecked: Checked Received: (qmail 7740 invoked from network); 7 Apr 2017 16:56:48 -0000 Received: from mail-wm0-f68.google.com (HELO mail-wm0-f68.google.com) (74.125.82.68) by server-13.tower-21.messagelabs.com with AES128-GCM-SHA256 encrypted SMTP; 7 Apr 2017 16:56:48 -0000 Received: by mail-wm0-f68.google.com with SMTP id o81so2360274wmb.0 for ; Fri, 07 Apr 2017 09:56:48 -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=P/k03/+RIKKD233zg4Fd+wNxCae2ye0coIi7twiNWRw=; b=pUOAHp1uPAi7Ud+T7O7YwQ0pZwunwBdQYVB/qpvot6gXFiQ53LjSrCD843Un0ruzEy ZeINxbMl3vqIgD5KStZNTTLGRvTu5AebG1dXm/XMeYYd00xz6r2qOXmOSpszW7xLoclC DrqW3TDVjdU5QpGjuTh+GhK8/PFqP7DAYasfMK3QwGpzNhzeQBAWPfZ2Ojc8A/+uyzLz J7VI+SLSS4Wx2TeS+MXsb15XgUH7/yU8OpU2cSgEWRo0VkBnfAzoTD2mqDag6bVDaTIi YZvGpf4SNHPxv1pW9+UKRSpwn811z/txoi64mzmjQUSmN7gSlj7/9V8gtdKHC1WJvPVp Itbw== 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=P/k03/+RIKKD233zg4Fd+wNxCae2ye0coIi7twiNWRw=; b=qoB+8DO3os+lG9nyPaPYSuVZ9c8PDXFlW7NwvJCIWOvCOKx/ptcV9njPN31hEY6GGT KS0DrCVQR5EokM5p2U7nTpNPLhfGiqScxXTBIYnCheC27Nd/hgLRMQXIuI46QO8GStif 7XxvUozze2HE8IZGnRjEOju3BRHwVIXuZmr4IHXDccz4ENwJP0WdMoo76lEyVFKAAqwy z0a2ufik0kX/mzm3GTBbQCjSOcusXHdMsd8UVt9XQGOjp18avgsKT8UdcuOYDHdjFFtR TGf/cD4op5E6OgfxCHJDLLUmZGBK/FzHgtgrScoeqzEs2ckV6N4cyBBcWyoWFajw0w1n XcHA== X-Gm-Message-State: AN3rC/5YY+bsCa2YF3SLLtU49gX9HGG4t8DpZuBfA79wbEBHjBxJziyn ro2/enaZOWaacSsG X-Received: by 10.28.66.207 with SMTP id k76mr273281wmi.121.1491584207767; Fri, 07 Apr 2017 09:56:47 -0700 (PDT) Received: from Solace.fritz.box ([80.66.223.217]) by smtp.gmail.com with ESMTPSA id v188sm6966378wmg.11.2017.04.07.09.56.46 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 07 Apr 2017 09:56:47 -0700 (PDT) From: Dario Faggioli To: xen-devel@lists.xenproject.org Date: Fri, 07 Apr 2017 18:56:45 +0200 Message-ID: <149158420588.32558.740383499165076337.stgit@Solace.fritz.box> In-Reply-To: <149158365254.32558.7658440932477066488.stgit@Solace.fritz.box> References: <149158365254.32558.7658440932477066488.stgit@Solace.fritz.box> User-Agent: StGit/0.17.1-dirty MIME-Version: 1.0 Cc: George Dunlap , Anshul Makkar Subject: [Xen-devel] [PATCH v3 3/7] xen: credit: consider tickled pCPUs as busy. 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 Currently, it can happen that __runq_tickle(), running on pCPU 2 because vCPU x woke up, decides to tickle pCPU 3, because it's idle. Just after that, but before pCPU 3 manages to schedule and pick up x, either __runq_tickel() or __csched_cpu_pick(), running on pCPU 6, sees that idle pCPUs are 0, 1 and also 3, and for whatever reason it also chooses 3 for waking up (or migrating) vCPU y. When pCPU 3 goes through the scheduler, it will pick up, say, vCPU x, and y will sit in its runqueue, even if there are idle pCPUs. Alleviate this by marking a pCPU to be idle right away when tickling it (like, e.g., it happens in Credit2). Note that this does not eliminate the race. That is not possible without introducing proper locking for the cpumasks the scheduler uses. It significantly reduces the window during which it can happen, though. Introduce proper locking for the cpumask can, in theory, be done, and may be investigated in future. It is a significant amount of work to do it properly (e.g., avoiding deadlock), and it is likely to adversely affect scalability, and so it may be a path it is just not worth following. Signed-off-by: Dario Faggioli Reviewed-by: George Dunlap --- Cc: George Dunlap Cc: Anshul Makkar --- Changes from v2: * add comments to better explain the meaning of the added ASSERT()-s. --- xen/common/sched_credit.c | 32 +++++++++++++++++++++++++++++--- 1 file changed, 29 insertions(+), 3 deletions(-) diff --git a/xen/common/sched_credit.c b/xen/common/sched_credit.c index 59ed4ca..7b4ea02 100644 --- a/xen/common/sched_credit.c +++ b/xen/common/sched_credit.c @@ -489,7 +489,17 @@ static inline void __runq_tickle(struct csched_vcpu *new) __trace_var(TRC_CSCHED_TICKLE, 1, sizeof(cpu), &cpu); } - /* Send scheduler interrupts to designated CPUs */ + /* + * Mark the designated CPUs as busy and send them all the scheduler + * interrupt. We need the for_each_cpu for dealing with the + * !opt_tickle_one_idle case. We must use cpumask_clear_cpu() and + * can't use cpumask_andnot(), because prv->idlers needs atomic access. + * + * In the default (and most common) case, when opt_rickle_one_idle is + * true, the loop does only one step, and only one bit is cleared. + */ + for_each_cpu(cpu, &mask) + cpumask_clear_cpu(cpu, prv->idlers); cpumask_raise_softirq(&mask, SCHEDULE_SOFTIRQ); } else @@ -990,6 +1000,13 @@ csched_vcpu_acct(struct csched_private *prv, unsigned int cpu) SCHED_VCPU_STAT_CRANK(svc, migrate_r); SCHED_STAT_CRANK(migrate_running); set_bit(_VPF_migrating, ¤t->pause_flags); + /* + * As we are about to tickle cpu, we should clear its bit in + * idlers. But, if we are here, it means there is someone running + * on it, and hence the bit must be zero already. + */ + ASSERT(!cpumask_test_cpu(cpu, + CSCHED_PRIV(per_cpu(scheduler, cpu))->idlers)); cpu_raise_softirq(cpu, SCHEDULE_SOFTIRQ); } } @@ -1082,13 +1099,22 @@ static void csched_vcpu_sleep(const struct scheduler *ops, struct vcpu *vc) { struct csched_vcpu * const svc = CSCHED_VCPU(vc); + unsigned int cpu = vc->processor; SCHED_STAT_CRANK(vcpu_sleep); BUG_ON( is_idle_vcpu(vc) ); - if ( curr_on_cpu(vc->processor) == vc ) - cpu_raise_softirq(vc->processor, SCHEDULE_SOFTIRQ); + if ( curr_on_cpu(cpu) == vc ) + { + /* + * We are about to tickle cpu, so we should clear its bit in idlers. + * But, we are here because vc is going to sleep while running on cpu, + * so the bit must be zero already. + */ + ASSERT(!cpumask_test_cpu(cpu, CSCHED_PRIV(per_cpu(scheduler, cpu))->idlers)); + cpu_raise_softirq(cpu, SCHEDULE_SOFTIRQ); + } else if ( __vcpu_on_runq(svc) ) __runq_remove(svc); }