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=-10.1 required=3.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY, SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_GIT autolearn=unavailable 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 283EAC3A5A2 for ; Sun, 22 Sep 2019 18:45:19 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 0423C21907 for ; Sun, 22 Sep 2019 18:45:19 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1569177919; bh=DWKtDScol93RdvJbv9yCwIQTJp8Y0GXPef1Cydqd2G8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:List-ID:From; b=TvRp6Ib1YoJqXf7rvtlwQ55g80YaVbER4sEXOaz+hNN8/KdFcO4MxDmRBymWUOlMX xVrv5itxGfOjozHFwUwHhnNL/UtPk9AfsI6hDJ5f1JhikmCL0nOFEK/3Xu6TFqHHJZ byRJqx8/4tAJ/7zRXoQzjXHrj7bGo1kIFDZUpOhQ= Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2389121AbfIVSpS (ORCPT ); Sun, 22 Sep 2019 14:45:18 -0400 Received: from mail.kernel.org ([198.145.29.99]:40748 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S2389027AbfIVSpL (ORCPT ); Sun, 22 Sep 2019 14:45:11 -0400 Received: from sasha-vm.mshome.net (c-73-47-72-35.hsd1.nh.comcast.net [73.47.72.35]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 8944720882; Sun, 22 Sep 2019 18:45:09 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1569177911; bh=DWKtDScol93RdvJbv9yCwIQTJp8Y0GXPef1Cydqd2G8=; h=From:To:Cc:Subject:Date:In-Reply-To:References:From; b=OdAya8tgh3AVInQPQUx0E84oaUpPMPp9S36a2GIc4ndDm/UQMBK1LAmvNn+P6zBfH HLEqL/W53kC1s1MLOh3Mn8QBJvDRAjRkChK5+zw6jYQpypMQG97o13hW0yT9MimH3O ZREPBTLH3g3jir/iJAZXPAULNZmPms6NaCYos8NE= From: Sasha Levin To: linux-kernel@vger.kernel.org, stable@vger.kernel.org Cc: Juri Lelli , Peter Zijlstra , =?UTF-8?q?Michal=20Koutn=C3=BD?= , Daniel Bristot de Oliveira , Tejun Heo , Linus Torvalds , Thomas Gleixner , lizefan@huawei.com, longman@redhat.com, luca.abeni@santannapisa.it, rostedt@goodmis.org, Ingo Molnar , Sasha Levin Subject: [PATCH AUTOSEL 5.3 026/203] sched/core: Fix CPU controller for !RT_GROUP_SCHED Date: Sun, 22 Sep 2019 14:40:52 -0400 Message-Id: <20190922184350.30563-26-sashal@kernel.org> X-Mailer: git-send-email 2.20.1 In-Reply-To: <20190922184350.30563-1-sashal@kernel.org> References: <20190922184350.30563-1-sashal@kernel.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-stable: review X-Patchwork-Hint: Ignore Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org From: Juri Lelli [ Upstream commit a07db5c0865799ebed1f88be0df50c581fb65029 ] On !CONFIG_RT_GROUP_SCHED configurations it is currently not possible to move RT tasks between cgroups to which CPU controller has been attached; but it is oddly possible to first move tasks around and then make them RT (setschedule to FIFO/RR). E.g.: # mkdir /sys/fs/cgroup/cpu,cpuacct/group1 # chrt -fp 10 $$ # echo $$ > /sys/fs/cgroup/cpu,cpuacct/group1/tasks bash: echo: write error: Invalid argument # chrt -op 0 $$ # echo $$ > /sys/fs/cgroup/cpu,cpuacct/group1/tasks # chrt -fp 10 $$ # cat /sys/fs/cgroup/cpu,cpuacct/group1/tasks 2345 2598 # chrt -p 2345 pid 2345's current scheduling policy: SCHED_FIFO pid 2345's current scheduling priority: 10 Also, as Michal noted, it is currently not possible to enable CPU controller on unified hierarchy with !CONFIG_RT_GROUP_SCHED (if there are any kernel RT threads in root cgroup, they can't be migrated to the newly created CPU controller's root in cgroup_update_dfl_csses()). Existing code comes with a comment saying the "we don't support RT-tasks being in separate groups". Such comment is however stale and belongs to pre-RT_GROUP_SCHED times. Also, it doesn't make much sense for !RT_GROUP_ SCHED configurations, since checks related to RT bandwidth are not performed at all in these cases. Make moving RT tasks between CPU controller groups viable by removing special case check for RT (and DEADLINE) tasks. Signed-off-by: Juri Lelli Signed-off-by: Peter Zijlstra (Intel) Reviewed-by: Michal Koutný Reviewed-by: Daniel Bristot de Oliveira Acked-by: Tejun Heo Cc: Linus Torvalds Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: lizefan@huawei.com Cc: longman@redhat.com Cc: luca.abeni@santannapisa.it Cc: rostedt@goodmis.org Link: https://lkml.kernel.org/r/20190719063455.27328-1-juri.lelli@redhat.com Signed-off-by: Ingo Molnar Signed-off-by: Sasha Levin --- kernel/sched/core.c | 4 ---- 1 file changed, 4 deletions(-) diff --git a/kernel/sched/core.c b/kernel/sched/core.c index 7fa8e74ad2ab4..d38f007afea74 100644 --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -6980,10 +6980,6 @@ static int cpu_cgroup_can_attach(struct cgroup_taskset *tset) #ifdef CONFIG_RT_GROUP_SCHED if (!sched_rt_can_attach(css_tg(css), task)) return -EINVAL; -#else - /* We don't support RT-tasks being in separate groups */ - if (task->sched_class != &fair_sched_class) - return -EINVAL; #endif /* * Serialize against wake_up_new_task() such that if its -- 2.20.1