Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751936AbdHXIbD (ORCPT ); Thu, 24 Aug 2017 04:31:03 -0400 Received: from foss.arm.com ([217.140.101.70]:37260 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751282AbdHXI30 (ORCPT ); Thu, 24 Aug 2017 04:29:26 -0400 Date: Thu, 24 Aug 2017 09:29:21 +0100 From: Juri Lelli To: Luca Abeni Cc: Mathieu Poirier , Ingo Molnar , Peter Zijlstra , tj@kernel.org, vbabka@suse.cz, Li Zefan , akpm@linux-foundation.org, weiyongjun1@huawei.com, 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: <20170824082921.qacztjez2uipsjm4@e106622-lin> References: <1502918443-30169-1-git-send-email-mathieu.poirier@linaro.org> <20170822142136.3604336e@luca> <20170824095326.4f5c1777@luca> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170824095326.4f5c1777@luca> User-Agent: NeoMutt/20170113 (1.7.2) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2183 Lines: 55 Hi, On 24/08/17 09:53, Luca Abeni wrote: > On Wed, 23 Aug 2017 13:47:13 -0600 > Mathieu Poirier wrote: > > >> This is a renewed attempt at fixing a problem reported by Steve Rostedt [1] > > >> where DL bandwidth accounting is not recomputed after CPUset and CPUhotplug > > >> operations. When CPUhotplug and some CUPset manipulation take place root > > >> domains are destroyed and new ones created, loosing at the same time DL > > >> accounting pertaining to utilisation. > > > > > > Thanks for looking at this longstanding issue! I am just back from > > > vacations; in the next days I'll try your patches. > > > Do you have some kind of scripts for reproducing the issue > > > automatically? (I see that in the original email Steven described how > > > to reproduce it manually; I just wonder if anyone already scripted the > > > test). > > > > I didn't bother scripting it since it is so easy to do. I'm eager to > > see how things work out on your end. > > Ok, so I'll try to reproduce the issue manually as described in Steven's > original email; I'll run some tests as soon as I finish with some stuff > that accumulated during vacations. > I have to apologize myself, as I suspect I won't have much time to properly review this set before LPC. :( I'll try my best to have a look though. [...] > > Nonetheless the approach I > > was contemplating was to repeat the current mathematics to all the > > root domains accessible from a p->cpus_allowed's flag. > > I think in the original SCHED_DEADLINE design there should be only one > root domain compatible with the task's affinity... If this does not > happen, I suspect it is a bug (Juri, can you confirm?). > > My understanding is that with SCHED_DEADLINE cpusets should be used to > partition the system's CPUs in disjoint sets (and I think there is one > root domain for each one of those disjoint sets). And the task affinity > mask should correspond with the CPUs composing the set in which the > task is executing. > Correct. No overlapping cpusets are allowed, and a task's affinity can't be restricted to a subset of the cpuset's root domain cpus. [...] Thanks, - Juri