From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-6.9 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_PASS,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 232D4C04A6B for ; Wed, 8 May 2019 09:24:50 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id EDF3620656 for ; Wed, 8 May 2019 09:24:49 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1727354AbfEHJYt (ORCPT ); Wed, 8 May 2019 05:24:49 -0400 Received: from mail.santannapisa.it ([193.205.80.98]:62470 "EHLO mail.santannapisa.it" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726806AbfEHJYs (ORCPT ); Wed, 8 May 2019 05:24:48 -0400 Received: from [83.43.182.198] (account l.abeni@santannapisa.it HELO nowhere) by santannapisa.it (CommuniGate Pro SMTP 6.1.11) with ESMTPSA id 138922343; Wed, 08 May 2019 11:24:45 +0200 Date: Wed, 8 May 2019 11:24:37 +0200 From: luca abeni To: Juri Lelli Cc: linux-kernel@vger.kernel.org, Greg Kroah-Hartman , "Rafael J . Wysocki" , Ingo Molnar , Peter Zijlstra , Vincent Guittot , "Paul E . McKenney" , Joel Fernandes , Quentin Perret , Luc Van Oostenryck , Morten Rasmussen , Daniel Bristot de Oliveira , Patrick Bellasi , Tommaso Cucinotta Subject: Re: [RFC PATCH 4/6] sched/dl: Improve capacity-aware wakeup Message-ID: <20190508112437.74661fa8@nowhere> In-Reply-To: <20190508090855.GG6551@localhost.localdomain> References: <20190506044836.2914-1-luca.abeni@santannapisa.it> <20190506044836.2914-5-luca.abeni@santannapisa.it> <20190508090855.GG6551@localhost.localdomain> Organization: Scuola Superiore S.Anna X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; 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 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 8 May 2019 11:08:55 +0200 Juri Lelli wrote: > On 06/05/19 06:48, Luca Abeni wrote: > > From: luca abeni > > > > Instead of considering the "static CPU bandwidth" allocated to > > a SCHED_DEADLINE task (ratio between its maximum runtime and > > reservation period), try to use the remaining runtime and time > > to scheduling deadline. > > > > Signed-off-by: luca abeni > > --- > > kernel/sched/cpudeadline.c | 9 +++++++-- > > 1 file changed, 7 insertions(+), 2 deletions(-) > > > > diff --git a/kernel/sched/cpudeadline.c b/kernel/sched/cpudeadline.c > > index d21f7905b9c1..111dd9ac837b 100644 > > --- a/kernel/sched/cpudeadline.c > > +++ b/kernel/sched/cpudeadline.c > > @@ -114,8 +114,13 @@ static inline int dl_task_fit(const struct > > sched_dl_entity *dl_se, int cpu, u64 *c) > > { > > u64 cap = (arch_scale_cpu_capacity(NULL, cpu) * > > arch_scale_freq_capacity(cpu)) >> SCHED_CAPACITY_SHIFT; > > - s64 rel_deadline = dl_se->dl_deadline; > > - u64 rem_runtime = dl_se->dl_runtime; > > + s64 rel_deadline = dl_se->deadline - > > sched_clock_cpu(smp_processor_id()); > > + u64 rem_runtime = dl_se->runtime; > > + > > + if ((rel_deadline < 0) || (rel_deadline * > > dl_se->dl_runtime < dl_se->dl_deadline * rem_runtime)) { > > + rel_deadline = dl_se->dl_deadline; > > + rem_runtime = dl_se->dl_runtime; > > + } > > So, are you basically checking if current remaining bw can be consumed > safely? I check if the current runtime (rescaled based on the capacity) is smaller than the time to the current scheduling deadline (basically, if it can be consumed in time). However, if q / (d - t) > Q / P (where "q" is the current runtime, "d" is the scheduling deadline, "Q" is the maximum runtime, and "P" is the CBS period), then a new scheduling deadline will be generated (later), and the runtime will be reset to Q... So, I need to use the maximum budget and CBS period for checking if the task fits in the core. > > I'm not actually sure if looking at dynamic values is what we need to > do at this stage. By considering static values we fix admission > control (and scheduling). Aren't dynamic values more to do with > energy tradeoffs (and so to be introduced when starting to look at > the energy model)? Using the current runtime and scheduling deadline might allow to migrate a task to SMALL cores (if its remaining runtime is small enough), even if the rescaled Q is larger than P. So, in theory it might allow to reduce the load on big cores. If we decide that this is overkilling, I can just drop the patch. Luca > Another pair of hands maybe is to look at the dynamic spare bw of CPUs > (to check that we don't overload CPUs). > > Thanks, > > - Juri