Received: by 2002:a25:4158:0:0:0:0:0 with SMTP id o85csp4757659yba; Wed, 8 May 2019 02:10:53 -0700 (PDT) X-Google-Smtp-Source: APXvYqxyG5EkrQkFy6PvVfNbZ8XJExB3Icy2h6k51iHYeVuIvOl2Wazq0Qqch0GPng4ksEx2H04Q X-Received: by 2002:a17:902:29c9:: with SMTP id h67mr46287662plb.114.1557306653544; Wed, 08 May 2019 02:10:53 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1557306653; cv=none; d=google.com; s=arc-20160816; b=W2r6LLzMURHFjW+VwfDdmRtHjjl2FT3cipch/SrPUd6ZMRVsk7iKgucviwCV2mfzhZ JR0QJYAWBI2u+PJbJAco2EN7VGDxEWp+K0B35H9XOpXwFdkEdPDMKUNONB0r3NQhCvs+ TgQbXYuO58BUbJOIYzm74csi6M50pyIaU7FfLtKBjGjgFmhAbxG4ESWi7hZC0D+tWVFM aXqhkyleL5U5PgRqxk9IN9i1O1q8u82IOiFlgseHgLI9UiJ2U7sCFJb+GE3ody6fgUj/ 4J9A5tWmrbQt+bYYYTfTvqBYZ8YYG05apxAV8USjfakNKwHM9IF/LtEByZ26ylDnhhOK wU1g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=78s6BKgtcqTpXSDR87S8iwsLLYq7TFH1AkHESOn6xdQ=; b=sbwO8atQQMowDMJ0gP1Lkghd2Rb3UfzxHsOvJ1jGSlTyQtmqD6UmuK2zBqa53Adg3k Jy9O4puGZWsMVDkdxX+EUrIH/9uFMcDeEAMTH8pXKkeHD4Do6cMEkBOY6Kt/k0w0nuck A1xYzRx+5nCEGd2YDHB1Rdg+41s/02On3mC6COXQvhsO9miLlJxTIhg4COYz+my9Pses vYDEuni/4clzZWBnfA4SoGN3cy/s21HobTGlG+cVUciStMkVMl1JwglZvtPVliPPNVCg xkDV2qXNu3zAs35ZSTKSJCso3z3RD+oE5nMS3QB1VcgjXmoq+0pQghvfdTcommRR7PUz fs/w== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m184si24870263pfb.166.2019.05.08.02.10.38; Wed, 08 May 2019 02:10:53 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726761AbfEHJJB (ORCPT + 99 others); Wed, 8 May 2019 05:09:01 -0400 Received: from mail-wm1-f66.google.com ([209.85.128.66]:35144 "EHLO mail-wm1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726163AbfEHJJA (ORCPT ); Wed, 8 May 2019 05:09:00 -0400 Received: by mail-wm1-f66.google.com with SMTP id y197so2247177wmd.0 for ; Wed, 08 May 2019 02:08:59 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=78s6BKgtcqTpXSDR87S8iwsLLYq7TFH1AkHESOn6xdQ=; b=ZyukzDvS7PWuP4WgsDsDU7PMxT5xaOC70mAhTrRmf2vFiu3aIj+FIrM0Ge69MZY7oB qXqm6G6R5xWFviVQnNTm3gma7puNduE8/kI93t1gXewtnu5J7OzfSHzg7lvnP5woGV6X USRCQSk/bJXOTDi/Uc3FTHcaXXs/maDgZtuGiqbLiCnJC9LZ5noi0lPIOpqaxCD3Lt7U LxDTpcdtbyuTokHPYWr3/ut268yHe4YYBaQyW28hW0c7QwPb7oGqwv2RmJZ3lu0bTqv5 hZ0NU2G1BK1rQzsDMHrTpNQAE4bitcpdjmrB7f2pxgXOfnksg313FzDnD0q5cmrSuAmi GaCA== X-Gm-Message-State: APjAAAXWy3HQD3yhpWdyovf8BNq9o9woxbvwtP7b0baRnLREWTNVd4PP 0lvBqOXGteQyj5IydeZQn3nLkw== X-Received: by 2002:a7b:ce03:: with SMTP id m3mr2013588wmc.99.1557306538566; Wed, 08 May 2019 02:08:58 -0700 (PDT) Received: from localhost.localdomain ([151.29.174.33]) by smtp.gmail.com with ESMTPSA id o4sm1417936wmc.38.2019.05.08.02.08.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 08 May 2019 02:08:57 -0700 (PDT) Date: Wed, 8 May 2019 11:08:55 +0200 From: Juri Lelli To: Luca Abeni 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: <20190508090855.GG6551@localhost.localdomain> References: <20190506044836.2914-1-luca.abeni@santannapisa.it> <20190506044836.2914-5-luca.abeni@santannapisa.it> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190506044836.2914-5-luca.abeni@santannapisa.it> User-Agent: Mutt/1.11.3 (2019-02-01) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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'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)? 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