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 B74DEC6FD1C for ; Wed, 22 Mar 2023 13:19:25 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230497AbjCVNTY (ORCPT ); Wed, 22 Mar 2023 09:19:24 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:51840 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S230515AbjCVNTJ (ORCPT ); Wed, 22 Mar 2023 09:19:09 -0400 Received: from foss.arm.com (foss.arm.com [217.140.110.172]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 3FC1127497; Wed, 22 Mar 2023 06:19:00 -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 E6F5A4B3; Wed, 22 Mar 2023 06:19:43 -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 65D3E3F6C4; Wed, 22 Mar 2023 06:18:56 -0700 (PDT) Message-ID: Date: Wed, 22 Mar 2023 14:18:47 +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: Juri Lelli , Waiman Long 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> From: Dietmar Eggemann In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15/03/2023 18: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? Moving the process instead of the individual tasks makes cpuset_can_attach() have to deal with multiple tasks. # ps2 | grep DLN 1614 1615 140 0 - DLN thread0-0 1614 1616 140 0 - DLN thread0-1 1614 1617 140 0 - DLN thread0-2 # echo 1614 > /sys/fs/cgroup/cpuset/cs2/cgroup.procs From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dietmar Eggemann Subject: Re: [RFC PATCH 2/3] sched/cpuset: Keep track of SCHED_DEADLINE tasks in cpusets Date: Wed, 22 Mar 2023 14:18:47 +0100 Message-ID: References: <20230315121812.206079-1-juri.lelli@redhat.com> <20230315121812.206079-3-juri.lelli@redhat.com> <7a3b31bf-4f6a-6525-9c6a-2bae44d7b0af@redhat.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: Content-Language: en-US In-Reply-To: List-ID: Content-Type: text/plain; charset="us-ascii" To: Juri Lelli , Waiman Long Cc: Peter Zijlstra , Ingo Molnar , Qais Yousef , Tejun Heo , Zefan Li , Johannes Weiner , Hao Luo , Steven Rostedt , linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, luca.abeni-5rdYK369eBLQB0XuIGIEkQ@public.gmane.org, claudio-YOzL5CV4y4YG1A2ADO40+w@public.gmane.org, tommaso.cucinotta-5rdYK369eBLQB0XuIGIEkQ@public.gmane.org, bristot-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org, mathieu.poirier-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org, cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Vincent Guittot , Wei Wang , Rick Yiu , Quentin Perret , Heiko Carstens , Vasily Gorbik , Alexander Gordeev , Sudeep Holla On 15/03/2023 18: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? Moving the process instead of the individual tasks makes cpuset_can_attach() have to deal with multiple tasks. # ps2 | grep DLN 1614 1615 140 0 - DLN thread0-0 1614 1616 140 0 - DLN thread0-1 1614 1617 140 0 - DLN thread0-2 # echo 1614 > /sys/fs/cgroup/cpuset/cs2/cgroup.procs