From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757583AbcBXVq5 (ORCPT ); Wed, 24 Feb 2016 16:46:57 -0500 Received: from mail-wm0-f44.google.com ([74.125.82.44]:37676 "EHLO mail-wm0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751750AbcBXVqz (ORCPT ); Wed, 24 Feb 2016 16:46:55 -0500 Date: Wed, 24 Feb 2016 22:46:43 +0100 From: luca abeni To: Peter Zijlstra Cc: Juri Lelli , Steven Rostedt , 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: <20160224224643.0a399506@utopia> In-Reply-To: <20160224191752.GD25010@twins.programming.kicks-ass.net> References: <20160210162748.GI11415@e106622-lin> <20160211121257.GL11415@e106622-lin> <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> X-Mailer: Claws Mail 3.12.0 (GTK+ 2.24.28; i686-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 Hi, On Wed, 24 Feb 2016 20:17:52 +0100 Peter Zijlstra wrote: > On Fri, Feb 12, 2016 at 06:05:30PM +0100, Peter Zijlstra wrote: > > Having two separate means of accounting this also feels more fragile > > than one would want. > > > > Let me think a bit about this. > > I think there's a fundamental problem that makes the whole notion of > per-rq accounting 'impossible'. > > On hot-unplug we only migrate runnable tasks, all blocked tasks remain > on the dead cpu. This would very much include their bandwidth > requirements. > > This means that between a hot-unplug and the moment that _all_ those > blocked tasks have ran at least once, the sum of online bandwidth > doesn't match and we can get into admission trouble (same for GRUB, > which can also use per-rq bw like this). After Juri's patch and emails, I tried to think about the CPU hot-(un)plugging issues, and to check if/how they affect GRUB reclaiming... I arrived to the conclusion that for GRUB this is not a problem (but, as usual, I might be wrong): GRUB just needs to track the per-runqueue active/inactive utilization, and is not badly affected by the fact that inactive utilization is migrated "too late" (when a task wakes up instead of when the CPU goes offline). This is because GRUB does not care about "global" utilization, but considers the various runqueues in isolation (there is a flavor of the m-grub algorithm that uses global inactive utilization, but it is not implemented by the patches I submitted). In other words: Juri's patch uses per-runqueue utilizations to re-build the global utilization, while GRUB does not care if the sum of the "active utilizations" match with the utilization used for admission control. I still have to check some details, and to run some more tests with CPU hot-(un)plug (and this is why I did not send a v2 of the reclaiming RFC yet)... In particular, I need to check what happens if the "inactive timer" fires when the CPU on which the task was running is already offline. Thanks, Luca