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 Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C2A83C6FD1F for ; Wed, 22 Mar 2023 14:05:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S231278AbjCVOF4 (ORCPT ); Wed, 22 Mar 2023 10:05:56 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53918 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231293AbjCVOFu (ORCPT ); Wed, 22 Mar 2023 10:05:50 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 26B17559D1; Wed, 22 Mar 2023 07:05:41 -0700 (PDT) Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id C57894B3; Wed, 22 Mar 2023 07:06:24 -0700 (PDT) Received: from [192.168.178.6] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 170F93F71E; Wed, 22 Mar 2023 07:05:36 -0700 (PDT) Message-ID: <848c4fb3-d3c4-a7f0-9df8-9b25c537f42c@arm.com> Date: Wed, 22 Mar 2023 15:05:25 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.8.0 Subject: Re: [RFC PATCH 2/3] sched/cpuset: Keep track of SCHED_DEADLINE tasks in cpusets Content-Language: en-US To: Waiman Long , Juri Lelli Cc: Peter Zijlstra , Ingo Molnar , Qais Yousef , Tejun Heo , Zefan Li , Johannes Weiner , Hao Luo , Steven Rostedt , linux-kernel@vger.kernel.org, luca.abeni@santannapisa.it, claudio@evidence.eu.com, tommaso.cucinotta@santannapisa.it, bristot@redhat.com, mathieu.poirier@linaro.org, cgroups@vger.kernel.org, Vincent Guittot , Wei Wang , Rick Yiu , Quentin Perret , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Sudeep Holla References: <20230315121812.206079-1-juri.lelli@redhat.com> <20230315121812.206079-3-juri.lelli@redhat.com> <7a3b31bf-4f6a-6525-9c6a-2bae44d7b0af@redhat.com> <2739c3ec-1e97-fc4d-8001-50283c94f4ff@redhat.com> From: Dietmar Eggemann In-Reply-To: <2739c3ec-1e97-fc4d-8001-50283c94f4ff@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15/03/2023 19:01, Waiman Long wrote: > > On 3/15/23 13:14, Juri Lelli wrote: >> On 15/03/23 11:46, Waiman Long wrote: >>> On 3/15/23 08:18, Juri Lelli wrote: [...] >>>> @@ -2472,6 +2492,11 @@ static int cpuset_can_attach(struct >>>> cgroup_taskset *tset) >>>>            ret = security_task_setscheduler(task); >>>>            if (ret) >>>>                goto out_unlock; >>>> + >>>> +        if (dl_task(task)) { >>>> +            cs->nr_deadline_tasks++; >>>> +            cpuset_attach_old_cs->nr_deadline_tasks--; >>>> +        } >>>>        } >>> Any one of the tasks in the cpuset can cause the test to fail and >>> abort the >>> attachment. I would suggest that you keep a deadline task transfer >>> count in >>> the loop and then update cs and cpouset_attach_old_cs only after all the >>> tasks have been iterated successfully. >> Right, Dietmar I think commented pointing out something along these >> lines. Think though we already have this problem with current >> task_can_attach -> dl_cpu_busy which reserves bandwidth for each tasks >> in the destination cs. Will need to look into that. Do you know which >> sort of operation would move multiple tasks at once? > > Actually, what I said previously may not be enough. There can be > multiple controllers attached to a cgroup. If any of thier can_attach() > calls fails, the whole transaction is aborted and cancel_attach() will > be called. My new suggestion is to add a new deadline task transfer > count into the cpuset structure and store the information there > temporarily. If cpuset_attach() is called, it means all the can_attach > calls succeed. You can then update the dl task count accordingly and > clear the temporary transfer count. > > I guess you may have to do something similar with dl_cpu_busy(). I gave it a shot: https://lkml.kernel.org/r/20230322135959.1998790-1-dietmar.eggemann@arm.com