From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965262AbcA1OBG (ORCPT ); Thu, 28 Jan 2016 09:01:06 -0500 Received: from casper.infradead.org ([85.118.1.10]:38922 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S964837AbcA1OA4 (ORCPT ); Thu, 28 Jan 2016 09:00:56 -0500 Date: Thu, 28 Jan 2016 15:00:53 +0100 From: Peter Zijlstra To: luca abeni Cc: linux-kernel@vger.kernel.org, Ingo Molnar , Juri Lelli Subject: Re: [RFC 4/8] Improve the tracking of active utilisation Message-ID: <20160128140053.GR6356@twins.programming.kicks-ass.net> References: <1452785094-3086-1-git-send-email-luca.abeni@unitn.it> <1452785094-3086-5-git-send-email-luca.abeni@unitn.it> <20160114194323.GC6357@twins.programming.kicks-ass.net> <569E29FD.9040909@unitn.it> <20160119134739.GY6357@twins.programming.kicks-ass.net> <20160127143651.4de18ad9@luca-1225C> <20160127143946.GR6357@twins.programming.kicks-ass.net> <20160128121441.0ebde65d@utopia> <20160128122100.GD6357@twins.programming.kicks-ass.net> <20160128144129.789ca176@utopia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20160128144129.789ca176@utopia> 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, Jan 28, 2016 at 02:41:29PM +0100, luca abeni wrote: > > Some day we should fix this :-) > I am trying to have a better look at the code, and I think that > implementing bandwidth inheritance (BWI) could be easy (implementing > M-BWI, that can be analyzed on multi-processor systems, is more complex > because it requires busy waiting or similar). Ah indeed, I remember now. To which I said that if busy-waiting is 'correct' so then must not busy-waiting be, for that consumes less cputime and would allow more actual work to be done. Of course, I might have missed some subtle detail, but intuition suggests the above. > > Nope, but fixing this is likely to be non-trivial. > Ok... So, if this is acceptable for this patchset I'll try to keep the > current PI behaviour, Yeah that's fine. That's decidedly outside the scope of these patches. > and I'll try to have a look at a better PI > protocol after the runtime reclaiming stuff is done (that is, I make it > acceptable for mainline, or we decide that a different approach is > needed). That would be very nice indeed!