From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-9.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS, USER_AGENT_GIT autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 0069DC76188 for ; Fri, 19 Jul 2019 14:00:55 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id D2C3B20873 for ; Fri, 19 Jul 2019 14:00:54 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729586AbfGSOAh (ORCPT ); Fri, 19 Jul 2019 10:00:37 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:51273 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729509AbfGSOAd (ORCPT ); Fri, 19 Jul 2019 10:00:33 -0400 Received: by mail-wm1-f66.google.com with SMTP id 207so28930482wma.1 for ; Fri, 19 Jul 2019 07:00:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=VKh5F3gMwRtIY8LwPbQ4AcnY8aG7rL1fZSwNVcviJak=; b=Ao7HT2lbeBOsNwUMUwo+PYzmGpnVu0gId3gdnZiNsY+GuTC+ZBju+ZL8MI8C8KvSy0 Xa8M1xzA8MCA/1BlhAou7xykqrQW1HNiRLnpnghoJBK8bu0dXTiRapgy2lU7E/ftGj9Q PMsMgbaLAEnprjewOxMMxDoh5zGn3Q/lApgssTwFiOXnaJMWj3vkrM0SUcTBNZzajJzS jiNw6zXv/CkyW5ScuIjitlT7ROftmoyhjiZaAHNt1u1DuYyhI4DGPwXmHt5w+rgPphxD 7ny2jheWJBAgpux3+uoUKkVL2wV77Z1C4W6QWdZTtA9M9aIr947ahdwbg9JoYisnKhEA 8p3g== X-Gm-Message-State: APjAAAWu6hukbf5GtDFVOn1hov/NyDE5cuw9TWXa/oaSEL+gb3Ox/P45 KTFwGrwsZce0b2RqSwPEiWNKhg== X-Google-Smtp-Source: APXvYqzIf60Lf9aSNAxg/yPyPA5RbNqgMkBFA3RSc1Y0RpcRDM61RivofduFeNa3XkVhrhm+B/NHYA== X-Received: by 2002:a1c:7c08:: with SMTP id x8mr48579844wmc.19.1563544831694; Fri, 19 Jul 2019 07:00:31 -0700 (PDT) Received: from localhost.localdomain.com ([151.15.230.231]) by smtp.gmail.com with ESMTPSA id f10sm21276926wrs.22.2019.07.19.07.00.30 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 19 Jul 2019 07:00:30 -0700 (PDT) From: Juri Lelli To: peterz@infradead.org, mingo@redhat.com, rostedt@goodmis.org, tj@kernel.org Cc: linux-kernel@vger.kernel.org, luca.abeni@santannapisa.it, claudio@evidence.eu.com, tommaso.cucinotta@santannapisa.it, bristot@redhat.com, mathieu.poirier@linaro.org, lizefan@huawei.com, longman@redhat.com, dietmar.eggemann@arm.com, cgroups@vger.kernel.org, Juri Lelli Subject: [PATCH v9 4/8] sched/deadline: Fix bandwidth accounting at all levels after offline migration Date: Fri, 19 Jul 2019 15:59:56 +0200 Message-Id: <20190719140000.31694-5-juri.lelli@redhat.com> X-Mailer: git-send-email 2.17.2 In-Reply-To: <20190719140000.31694-1-juri.lelli@redhat.com> References: <20190719140000.31694-1-juri.lelli@redhat.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org If a task happens to be throttled while the CPU it was running on gets hotplugged off, the bandwidth associated with the task is not correctly migrated with it when the replenishment timer fires (offline_migration). Fix things up, for this_bw, running_bw and total_bw, when replenishment timer fires and task is migrated (dl_task_offline_migration()). Signed-off-by: Juri Lelli --- kernel/sched/deadline.c | 33 +++++++++++++++++++++++++++++++++ 1 file changed, 33 insertions(+) diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c index 4cedcf8d6b03..f0166ab8c6b4 100644 --- a/kernel/sched/deadline.c +++ b/kernel/sched/deadline.c @@ -529,6 +529,7 @@ static struct rq *find_lock_later_rq(struct task_struct *task, struct rq *rq); static struct rq *dl_task_offline_migration(struct rq *rq, struct task_struct *p) { struct rq *later_rq = NULL; + struct dl_bw *dl_b; later_rq = find_lock_later_rq(p, rq); if (!later_rq) { @@ -557,6 +558,38 @@ static struct rq *dl_task_offline_migration(struct rq *rq, struct task_struct *p double_lock_balance(rq, later_rq); } + if (p->dl.dl_non_contending || p->dl.dl_throttled) { + /* + * Inactive timer is armed (or callback is running, but + * waiting for us to release rq locks). In any case, when it + * will file (or continue), it will see running_bw of this + * task migrated to later_rq (and correctly handle it). + */ + sub_running_bw(&p->dl, &rq->dl); + sub_rq_bw(&p->dl, &rq->dl); + + add_rq_bw(&p->dl, &later_rq->dl); + add_running_bw(&p->dl, &later_rq->dl); + } else { + sub_rq_bw(&p->dl, &rq->dl); + add_rq_bw(&p->dl, &later_rq->dl); + } + + /* + * And we finally need to fixup root_domain(s) bandwidth accounting, + * since p is still hanging out in the old (now moved to default) root + * domain. + */ + dl_b = &rq->rd->dl_bw; + raw_spin_lock(&dl_b->lock); + __dl_sub(dl_b, p->dl.dl_bw, cpumask_weight(rq->rd->span)); + raw_spin_unlock(&dl_b->lock); + + dl_b = &later_rq->rd->dl_bw; + raw_spin_lock(&dl_b->lock); + __dl_add(dl_b, p->dl.dl_bw, cpumask_weight(later_rq->rd->span)); + raw_spin_unlock(&dl_b->lock); + set_task_cpu(p, later_rq->cpu); double_unlock_balance(later_rq, rq); -- 2.17.2