Received: by 2002:a25:824b:0:0:0:0:0 with SMTP id d11csp3123628ybn; Fri, 27 Sep 2019 01:13:38 -0700 (PDT) X-Google-Smtp-Source: APXvYqx31h5YfOXjWPnf0rYt0E2pha5R1DrRmkjTbtjSTIePPtjt3PLvh+W+Is/d6xplX6kh3xyl X-Received: by 2002:a17:906:ecf9:: with SMTP id qt25mr6570904ejb.249.1569572018439; Fri, 27 Sep 2019 01:13:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1569572018; cv=none; d=google.com; s=arc-20160816; b=WO/Zm+j5C3Uu+ZXCrUoWsA1uduWzwiO3oP51FtwFZxObBsO5iGs4hI5JCjMtPABqJ7 p8AqeSHHzXwobDq4CjebHs3F5k7q2Eutb8CP2HaKkJxHYN7w5SVmEF0hiDP/qG9GxL6B ko5hT+z/H37eqfBWpGNand/EB/hfcoz+szFeslXZ5TDgW/x5bW9CxACadsJPOKUNJLHm 0nx6FZFaEWffpewqftXiKlhniBGMKqRHAsU3fF3VY+I/dwoS0cg8O+Wsi3LUcPgmynSv PO/7b5X3Bx41+F1mWghpA9qNHtZ3mexTDlggFC+P1yqXBy/RinhxZyp0GaMEDzvSVoww uxKQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=pPrTuKk2wLdZOfUDuO7yrMjO/e9382JtMmczzGLdwP4=; b=JGh/6fEiv71woOEFkdd16bTyZDTnT6fsHNmrtbVLpl+klNWEeIqGocQ2N/hehUrVuP 2hUtiO0oNDgiTl5hvw1F43BV9mS6ubZHStkjDibKjia5s6w1XgzGoG+l1ABDjWuXuU2I nmugHjCxVr+PvUXH3HhZoajFZBbncL8/gdxNLhKkV7h7UB2mXLMBww6yLfYGRCFg5G3a XpR4HSJXG/GBTeKFDEo3lgZ9NPl2y5370IKurEXIQiKcCaq5n1q4KV/0mjOT6+oZIpOj qtBGE4AtIcI0KvyMJBtZxGt2rU/3sX70XvK2PsHRnmGCBXQ0Dw84lhUbTbIWOvzA8O7S gZ9w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id op27si2507205ejb.253.2019.09.27.01.13.13; Fri, 27 Sep 2019 01:13:38 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727229AbfI0ILr (ORCPT + 99 others); Fri, 27 Sep 2019 04:11:47 -0400 Received: from mx1.redhat.com ([209.132.183.28]:40828 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726404AbfI0ILq (ORCPT ); Fri, 27 Sep 2019 04:11:46 -0400 Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E80C9CA38C for ; Fri, 27 Sep 2019 08:11:45 +0000 (UTC) Received: by mail-wr1-f71.google.com with SMTP id m14so680609wru.17 for ; Fri, 27 Sep 2019 01:11:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=pPrTuKk2wLdZOfUDuO7yrMjO/e9382JtMmczzGLdwP4=; b=XpynXCmjMtFs/vIy4aI9C1j6gaI8rBSt1liGm5Uaii0vvyr+o44moCGL9H9alObIba qEcpFicd3rNt6BYf1GfdTiOmsptJPZFA/oeEY1MtDjfDG7tEjVF7+33iX2rfcsByBrV8 XS6QWwOxfBGHxn62Kd9Ov9IyDnJfNmnrofkUoQmfyGKsHhwEunzQikXg0sYfd1LbdVKI IALlWfYu7lwcMIxyZ9tDWCW+dWCCXN9L5fUcA1c4F6fcwOg+cW26dNM7bxCsluW8MT/W oYKIQTpkugaeKJZws2SHb2T8I14UAbSIQ4EMlpfPXVmNEoZpBoz5KMUiSiwY4cUNJcWp i+oQ== X-Gm-Message-State: APjAAAXVt2msnkxg/HfSCcXOL6ltc8zkR/sMZXoZeRG3xvdYBb4qwDP8 wWKLgvNdWlTl8AT7Tqkfg/ifi2HbA+CqkwP6kLVS6KCiEUQKwxdgrOtlTIYo4yKXw4ko6Au4pYs fWyTKEHjfUrmq+4aE5Anyt+hX X-Received: by 2002:a1c:7418:: with SMTP id p24mr5857440wmc.132.1569571904507; Fri, 27 Sep 2019 01:11:44 -0700 (PDT) X-Received: by 2002:a1c:7418:: with SMTP id p24mr5857414wmc.132.1569571904151; Fri, 27 Sep 2019 01:11:44 -0700 (PDT) Received: from localhost.localdomain ([151.29.237.241]) by smtp.gmail.com with ESMTPSA id q3sm1688984wrm.86.2019.09.27.01.11.43 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 27 Sep 2019 01:11:43 -0700 (PDT) Date: Fri, 27 Sep 2019 10:11:41 +0200 From: Juri Lelli To: Scott Wood Cc: Sebastian Andrzej Siewior , Thomas Gleixner , Steven Rostedt , Peter Zijlstra , Daniel Bristot de Oliveira , Clark Williams , linux-kernel@vger.kernel.org, linux-rt-users@vger.kernel.org Subject: Re: [PATCH RT 5/8] sched/deadline: Reclaim cpuset bandwidth in .migrate_task_rq() Message-ID: <20190927081141.GB31660@localhost.localdomain> References: <20190727055638.20443-1-swood@redhat.com> <20190727055638.20443-6-swood@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190727055638.20443-6-swood@redhat.com> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Scott, On 27/07/19 00:56, Scott Wood wrote: > With the changes to migrate disabling, ->set_cpus_allowed() no longer > gets deferred until migrate_enable(). To avoid releasing the bandwidth > while the task may still be executing on the old CPU, move the subtraction > to ->migrate_task_rq(). > > Signed-off-by: Scott Wood > --- > kernel/sched/deadline.c | 67 +++++++++++++++++++++++-------------------------- > 1 file changed, 31 insertions(+), 36 deletions(-) > > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c > index c18be51f7608..2f18d0cf1b56 100644 > --- a/kernel/sched/deadline.c > +++ b/kernel/sched/deadline.c > @@ -1606,14 +1606,42 @@ static void yield_task_dl(struct rq *rq) > return cpu; > } > > +static void free_old_cpuset_bw_dl(struct rq *rq, struct task_struct *p) > +{ > + struct root_domain *src_rd = rq->rd; > + > + /* > + * Migrating a SCHED_DEADLINE task between exclusive > + * cpusets (different root_domains) entails a bandwidth > + * update. We already made space for us in the destination > + * domain (see cpuset_can_attach()). > + */ > + if (!cpumask_intersects(src_rd->span, p->cpus_ptr)) { > + struct dl_bw *src_dl_b; > + > + src_dl_b = dl_bw_of(cpu_of(rq)); > + /* > + * We now free resources of the root_domain we are migrating > + * off. In the worst case, sched_setattr() may temporary fail > + * until we complete the update. > + */ > + raw_spin_lock(&src_dl_b->lock); > + __dl_sub(src_dl_b, p->dl.dl_bw, dl_bw_cpus(task_cpu(p))); > + raw_spin_unlock(&src_dl_b->lock); > + } > +} > + > static void migrate_task_rq_dl(struct task_struct *p, int new_cpu __maybe_unused) > { > struct rq *rq; > > - if (p->state != TASK_WAKING) > + rq = task_rq(p); > + > + if (p->state != TASK_WAKING) { > + free_old_cpuset_bw_dl(rq, p); What happens if a DEADLINE task is moved between cpusets while it was sleeping? Don't we miss removing from the old cpuset if the task gets migrated on wakeup? Thanks, Juri