Received: by 10.223.176.5 with SMTP id f5csp2978524wra; Thu, 1 Feb 2018 08:55:12 -0800 (PST) X-Google-Smtp-Source: AH8x2277jAY921dDzbqxeDw3o79o8hd/aVSxynmvg8NLBT6zjvUaox558XP51+4Ega+lHQ2YcUca X-Received: by 10.99.164.25 with SMTP id c25mr29370704pgf.430.1517504112492; Thu, 01 Feb 2018 08:55:12 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1517504112; cv=none; d=google.com; s=arc-20160816; b=GHKFUrAVVtugKehHEjiNO2ijdpUjzcy7nyP10FEeonzHypQSaI0RZh5007ZJ45UWc4 IHoJ1Re22S/e6PfQTfV8w19+05t+v+buCc3gswVVOsdNHibAZ5KCUOl7lB2AxDpCONMr jB+rCNWJpaED8lRPTAR6uC3AWxsWGkw+lsLY1Xx6XEM1j/OqHZGhgGLWP+pk7ruxpz6b EWDYeXyyTCTARj8+I4TOrmG2/D49UFyxSHqqDTiT6LwbjH751cObkLoxBnSjV5a24ghA h7Yp20zDlBgeRbuv48NnNWTpPE9rnB3zL8HfV7h7JlspErBcHuT6omEjtTpxTnxyUbyA sp5A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:references:in-reply-to:message-id:date :subject:cc:to:from:dkim-signature:arc-authentication-results; bh=bbSpz/uy+1sO31tcIPzjYC71AHXRgGxlaVBZKzn4+Mw=; b=rNuf/glaj7jayxjdOnZS1KHMwVpudRrHsykvaflVRrKltKxH/QlOOAJ0kG0wgQBuP1 V6h0eJEKDM2NTZNtSpclcKSNzUSrorYXdcKqfrE72UrKYcQaTNi7ACinTG3sxuLCp+rt UMq5mk/g0sL67SRChnZ6w0t9tTFCVJzJJOyVh3qLO1uE7/gqe6EQW4PWH/4YF84fgr43 EXUTbtUvlkcRckGfQyrHuKZDB+kQelJEwNG0J/riodon3YE61KLyiGxI6QDP/OruP4eY BR43SkcGHYwkrPooSI/96DRYMUWjkm//ptZvbs6EFdk1Qf4LxFbnED9B3DPGvpq9BO+i OKFg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linaro.org header.s=google header.b=T2oFwe9G; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id a15si5335096pgd.21.2018.02.01.08.54.57; Thu, 01 Feb 2018 08:55:12 -0800 (PST) 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; dkim=pass header.i=@linaro.org header.s=google header.b=T2oFwe9G; 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=pass (p=NONE sp=NONE dis=NONE) header.from=linaro.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752885AbeBAQwc (ORCPT + 99 others); Thu, 1 Feb 2018 11:52:32 -0500 Received: from mail-it0-f67.google.com ([209.85.214.67]:40923 "EHLO mail-it0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752799AbeBAQvX (ORCPT ); Thu, 1 Feb 2018 11:51:23 -0500 Received: by mail-it0-f67.google.com with SMTP id 196so4544748iti.5 for ; Thu, 01 Feb 2018 08:51:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=from:to:cc:subject:date:message-id:in-reply-to:references; bh=bbSpz/uy+1sO31tcIPzjYC71AHXRgGxlaVBZKzn4+Mw=; b=T2oFwe9GY8/f6yYxPY2NY8IED1Y8GGwu/W0XpqjBr8EQJaBuOBogxUKEqHBzhl3Z3j udyblpy/pXF2SGCzB02wx/4IhbcRz6rFH8CLYb5/XTt3HoMSzRRbMBWoe/s0OKopIYlO mFivFrZxVynj0kB016B9uWzOP4mul21Mvu5qI= 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=bbSpz/uy+1sO31tcIPzjYC71AHXRgGxlaVBZKzn4+Mw=; b=WWRezoE1BE+UMHXYPju3kbx6fpVUL3Lc3nbpabnrMfM1boWPu75cFqEAHR2LBGe8QR 9ZO0KEjW/2xPqg8y/5XsVwwvbNLJ7CxDf+6V3jrnlUyGojF5svfG/bCZyHT8H6nwLFj0 8mZbUzC4L2PnVAgEHOGs0HNNgHr1SwMsto770X3Hf0S1DRu3X8Hvtcx1cXPXKSUw9hzF v2tDKSP75nvY5bqVsBILeLRGWQPaNA4N3/REIuqlpOZ/i4Dy0KNKk4NEOdpZvb9amwAv vr5YOouYuRen2JHJ44mae4bZj5KdW6zxpmrKzDQW6Ng/3yKaLMbP5+OhA+erRuuer52T 9spg== X-Gm-Message-State: AKwxytcVc3ryaxWzq9q0IcC7xl7isj6Y2lcGiU1lBGEO+jh6FaT1eCPh 2zYbFS7inEBOxNFxR+sglGp1jg== X-Received: by 10.36.73.69 with SMTP id z66mr38070440ita.98.1517503882891; Thu, 01 Feb 2018 08:51:22 -0800 (PST) Received: from xps15.cg.shawcable.net (S0106002369de4dac.cg.shawcable.net. [68.147.8.254]) by smtp.gmail.com with ESMTPSA id e83sm9270773iof.71.2018.02.01.08.51.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 01 Feb 2018 08:51:22 -0800 (PST) From: Mathieu Poirier To: peterz@infradead.org Cc: lizefan@huawei.com, mingo@redhat.com, rostedt@goodmis.org, claudio@evidence.eu.com, bristot@redhat.com, tommaso.cucinotta@santannapisa.it, juri.lelli@redhat.com, luca.abeni@santannapisa.it, linux-kernel@vger.kernel.org Subject: [PATCH V2 6/7] sched/core: Don't change the affinity of DL tasks Date: Thu, 1 Feb 2018 09:51:08 -0700 Message-Id: <1517503869-3179-7-git-send-email-mathieu.poirier@linaro.org> X-Mailer: git-send-email 2.7.4 In-Reply-To: <1517503869-3179-1-git-send-email-mathieu.poirier@linaro.org> References: <1517503869-3179-1-git-send-email-mathieu.poirier@linaro.org> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Now that we mandate that on creation, the ->cpus_allowed mask of a future DL task has to be equal to the rd->span of the root domain it will be associated with, changing the affinity of a DL task doesn't make sense anymore. Indeed, if we set the task to a smaller affinity set then we may be running out of CPU cycle. If we try to increase the size of the affinity set the new CPUs are necessarily part of another root domain where DL utilisation for the task won't be accounted for. As such simply refuse to change the affinity set of a DL task. Signed-off-by: Mathieu Poirier --- kernel/sched/core.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 1a64aad1b9dc..2c9e54aac3cc 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -4694,15 +4694,15 @@ long sched_setaffinity(pid_t pid, const struct cpumask *in_mask) cpumask_and(new_mask, in_mask, cpus_allowed); /* - * Since bandwidth control happens on root_domain basis, - * if admission test is enabled, we only admit -deadline - * tasks allowed to run on all the CPUs in the task's - * root_domain. + * Since bandwidth control happens on root_domain basis, if admission + * test is enabled we don't allow the task' CPUs to change. If + * @new_mask is smaller than we risk running out of cycles. If it is + * bigger than we may be using DL bandwidth allocated to other CPUs. */ #ifdef CONFIG_SMP if (task_has_dl_policy(p) && dl_bandwidth_enabled()) { rcu_read_lock(); - if (!cpumask_subset(task_rq(p)->rd->span, new_mask)) { + if (!cpumask_equal(task_rq(p)->rd->span, new_mask)) { retval = -EBUSY; rcu_read_unlock(); goto out_free_new_mask; -- 2.7.4