From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932636AbcBYKUr (ORCPT ); Thu, 25 Feb 2016 05:20:47 -0500 Received: from bombadil.infradead.org ([198.137.202.9]:54625 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752104AbcBYKUn (ORCPT ); Thu, 25 Feb 2016 05:20:43 -0500 Date: Thu, 25 Feb 2016 11:20:34 +0100 From: Peter Zijlstra To: Juri Lelli Cc: Steven Rostedt , luca abeni , linux-kernel@vger.kernel.org, mingo@redhat.com, vincent.guittot@linaro.org, wanpeng.li@hotmail.com Subject: Re: [PATCH 1/2] sched/deadline: add per rq tracking of admitted bandwidth Message-ID: <20160225102034.GE6357@twins.programming.kicks-ass.net> References: <20160211132254.1a369fe9@utopia> <20160211122754.GN11415@e106622-lin> <20160211134018.6b15fd68@utopia> <20160211124959.GO11415@e106622-lin> <20160211140545.3c9e6e41@utopia> <20160211092546.5b607147@gandalf.local.home> <20160211171012.GS11415@e106622-lin> <20160212170530.GU6357@twins.programming.kicks-ass.net> <20160224191752.GD25010@twins.programming.kicks-ass.net> <20160225100706.GB3680@pablo> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160225100706.GB3680@pablo> User-Agent: Mutt/1.5.21 (2012-12-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, Feb 25, 2016 at 10:07:06AM +0000, Juri Lelli wrote: > Argh, this makes lot of sense to me. I've actually pondered a tree/list > solution, but then decided to try the cumulative approach because it > looked nicer. But it contains holes, I'm afraid. As Luca already said, > GRUB shouldn't have these problems though. > > I'll try and see what introducting a list of blocked/throttled deadline > tasks means, considering also the interaction with cpusets and such. > Maybe it's simpler than it seems. > > I'm not sure this will come anytime soon, unfortunately. I'm almost 100% > on the sched-freq/schedutil discussion these days. Just skip sleep and write them when its dark outside :-) > Anyway, do you also think that what we want to solve the root domain > issue is something based on rq_online/offline and per-rq information? > Everything else that I tried or thought of was broken/more horrible. :-/ I was still trying to get my head around this, the above was my suggestion to the per-rq state, but I've not thought hard on alternative approaches to the root_domain issue.