Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755283AbdHYJwS (ORCPT ); Fri, 25 Aug 2017 05:52:18 -0400 Received: from mail.sssup.it ([193.205.80.98]:42006 "EHLO mail.santannapisa.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754666AbdHYJwQ (ORCPT ); Fri, 25 Aug 2017 05:52:16 -0400 Date: Fri, 25 Aug 2017 11:52:09 +0200 From: Luca Abeni To: Mathieu Poirier Cc: Ingo Molnar , Peter Zijlstra , tj@kernel.org, vbabka@suse.cz, Li Zefan , akpm@linux-foundation.org, weiyongjun1@huawei.com, Juri Lelli , Steven Rostedt , Claudio Scordino , Daniel Bristot de Oliveira , "linux-kernel@vger.kernel.org" , Tommaso Cucinotta Subject: Re: [PATCH 0/7] sched/deadline: fix cpusets bandwidth accounting Message-ID: <20170825115209.44a6b042@luca> In-Reply-To: <20170825080243.7591aa0c@sweethome> References: <1502918443-30169-1-git-send-email-mathieu.poirier@linaro.org> <20170822142136.3604336e@luca> <20170824095326.4f5c1777@luca> <20170825080243.7591aa0c@sweethome> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.30; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2273 Lines: 53 On Fri, 25 Aug 2017 08:02:43 +0200 luca abeni wrote: [...] > > The above demonstrate that even if we have two CPUsets new task belong > > to the "default" CPUset and as such can use all the available CPUs. > > I still have a doubt (probably showing all my ignorance about > CPUsets :)... In this situation, we have 3 CPUsets: "default", > set1, and set2... Is everyone of these CPUsets associated to a > root domain (so, we have 3 root domains)? Or only set1 and set2 are > associated to a root domain? Ok, after reading (and hopefully understanding better :) the code, I think this question was kind of silly... There are only 2 root domains, corresponding to set1 and set2 (right?). [...] > > So above we'd run the acceptance test on root > > domain A and B before promoting the task. Of course we'd also have to > > add the utilisation of that task to both root domain. Although simple > > it goes at the core of the DL scheduler and touches pretty much every > > aspect of it, something I'm reluctant to embark on. > > I see... So, the "default" CPUset does not have any root domain > associated to it? If it had, we could just subtract the maximum > utilizations of set1 and set2 to it when creating the root domains of > set1 and set2. ... So, this idea of mine had no sense. I think the correct solution is what you implemented in your patchset (if I understand it correctly). If we want to have task spanning multiple root domains, many more changes in the code are needed... I am wondering if it would make more sense to track utilizations per runqueue (instead of per root domain): - when a task tries to become SCHED_DEADLINE, we count how many CPUs are in its affinity mask. Let's call "n" this number - then, we sum u / n (where "u" is the task's utilization) to the utilization of every runqueue that is in its affinity mask, and we check if all the sums are below the schedulability bound For tasks spanning one single root domain, this should be equivalent to the current admission test. Moreover, this check should ensure that no root domain can be ever overloaded (even if tasks span multiple domains). But I do not know the locking implications for this idea... I suspect it will not scale :( Luca