Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp1531715ybz; Thu, 16 Apr 2020 10:48:50 -0700 (PDT) X-Google-Smtp-Source: APiQypJ0jsPZBnDg3wwODPUKTHuebK4oiRsUsbo+d2DeRhLNCjvUIAf4I/pP0HyCa04YY2CCRe4r X-Received: by 2002:a50:ef16:: with SMTP id m22mr31829320eds.82.1587059330566; Thu, 16 Apr 2020 10:48:50 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587059330; cv=none; d=google.com; s=arc-20160816; b=zvXF3g2HuoVqy7T4qQzFFKrokdY5rCf+3mDPe8l9kqxvjtcDkd4/KlT/zd28AcRSw/ x84CFTbyC7wfOHkdnajfHVdFPs/Kdf4yErLwMEpza3CLuGw22n4l0LrHQT7haoUQ7n/h H62u5ihbwYQ8XSN0sVD/1DIfjiXwf/WGl4kgfMkYHGqo0ZT1TA501xYMuEYpusKCxFN4 1qgjAh6DGvyge/BX6QfZCPVVi/TE/lUKQfFTm7wb9aemVjEjlW21GDIOrNrQ8nOJPUwa 1hrw8tX6lErl0V0wuQ/SJAMKC5Fd2Rkdpig3qkeeRrK8IET0uink4bK1i5cus2L+4hip W9vA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :dkim-signature; bh=Rtsrb+mX+YQpZoHIv9A5wAzihBkDRNbltom382I4FVo=; b=AjpIuN/X7+PDuz20cQbnhRml3KybMylKKKMQ+HraYCka+Em/bZYsqGqskj0QV1skLL SV3vUG0XHLhngutifd1obSYXkTERfnrRmz/yv8rFG2n7EM3P4aMG0PPDeGl+UxqKGHqQ XHX3Wr7SIxKtiVKBn3HjePn9kFfW0IV2mcKq/Xb2rj1F7+cmWVlaDpzVqZc1Yj1Z3OHf e4X3QK838AAoSsjCZA6ECKTLIkwoNpQ6hTce0FOavPZNXhsIDJLV/WXTHSlZ0hvF+uq/ QIriy5l/FchMUe8EGimNxMH8oOKlRuCaRfEsHMc43QqyLBG7y68NtG0n18Crzt5ytPMa Yvmw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="b/4D2sVY"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id g5si8605092edu.188.2020.04.16.10.48.27; Thu, 16 Apr 2020 10:48:50 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="b/4D2sVY"; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S2895124AbgDPNTt (ORCPT + 99 others); Thu, 16 Apr 2020 09:19:49 -0400 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:37247 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2895029AbgDPNTq (ORCPT ); Thu, 16 Apr 2020 09:19:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1587043184; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=Rtsrb+mX+YQpZoHIv9A5wAzihBkDRNbltom382I4FVo=; b=b/4D2sVYvaBHjfhi9cDI55/+O7BHHFKEy2S4Ui+hPBRKGtn8kqdDYZgeIE4sm4L1t8BqRM 9/D3UTVXlLHEi/d2ItHuDgfoeY3KTh2Pvc/JHoDb6zSW9ZCTB2k94Tg90sZvu2BdmgwaB5 2V4OpiygFsadZ2+MLzczXWomRCg1oyY= Received: from mail-wm1-f70.google.com (mail-wm1-f70.google.com [209.85.128.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-410-kK-LLeTzNYWmW-uqBJS6Ng-1; Thu, 16 Apr 2020 09:19:43 -0400 X-MC-Unique: kK-LLeTzNYWmW-uqBJS6Ng-1 Received: by mail-wm1-f70.google.com with SMTP id b203so1169990wmd.6 for ; Thu, 16 Apr 2020 06:19:42 -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; bh=Rtsrb+mX+YQpZoHIv9A5wAzihBkDRNbltom382I4FVo=; b=hzmWFu4TeBdA6SS8maIxlj5fNY1ooKhCVisCbS4uMiMjYhhPEetgP29PseenPUklIt KgabnDuWk2dyD8FbC29+Eb+gcQWxaU0oCKDqVzNqfITL62SDsctV3kIWNiXq8Cf6Cdrq dwI2TTDZKcNt1bK8BlKI7LVEuqWmjsmYVrVI1rMxRAsNqtcivYUzSiXuMj3+cYBL6kQa CSjoaKnI15ZzPK5JKUwxiLmEjSv8317+6DPRq7NY7ZBuyak26WKx96QXpyGHZw3W63mh HHihE1OaOtif8oVbhP0tvN2pU89K8m0h26onTRlG381XfaWv291p0Da+6nOkIkso73l2 HGiQ== X-Gm-Message-State: AGi0Pub2e/e5xaxJlvGTPLig1l47YE3OF8q8/p5vyTIoYAEvfqVkzf1x Kn0JCBSiyJbDqO8+HcQYqNh4DJNUumdrAq4qyRW907f73MlNzfkkDi20bfy4fY2Az8K8o70nLD4 wyWEIB17OazqtNonaCpQFoQmJ X-Received: by 2002:a5d:6a92:: with SMTP id s18mr32571175wru.50.1587043181734; Thu, 16 Apr 2020 06:19:41 -0700 (PDT) X-Received: by 2002:a5d:6a92:: with SMTP id s18mr32571156wru.50.1587043181443; Thu, 16 Apr 2020 06:19:41 -0700 (PDT) Received: from localhost.localdomain ([151.29.194.179]) by smtp.gmail.com with ESMTPSA id l15sm3543650wmi.48.2020.04.16.06.19.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 16 Apr 2020 06:19:40 -0700 (PDT) Date: Thu, 16 Apr 2020 15:19:38 +0200 From: Juri Lelli To: luca abeni Cc: Dietmar Eggemann , Ingo Molnar , Peter Zijlstra , Vincent Guittot , Steven Rostedt , Daniel Bristot de Oliveira , Wei Wang , Quentin Perret , Alessio Balsini , Pavan Kondeti , Patrick Bellasi , Morten Rasmussen , Valentin Schneider , Qais Yousef , linux-kernel@vger.kernel.org Subject: Re: [PATCH 3/4] sched/deadline: Make DL capacity-aware Message-ID: <20200416131938.GI9767@localhost.localdomain> References: <20200408095012.3819-1-dietmar.eggemann@arm.com> <20200408095012.3819-4-dietmar.eggemann@arm.com> <20200410125253.GE14300@localhost.localdomain> <20200415132004.GF9767@localhost.localdomain> <20200415184203.50862783@sweethome> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200415184203.50862783@sweethome> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 15/04/20 18:42, luca abeni wrote: > Hi Juri, > > On Wed, 15 Apr 2020 15:20:04 +0200 > Juri Lelli wrote: > [...] > > > > I'm thinking that, while dl_task_fits_capacity() works well when > > > > selecting idle cpus, in this case we should consider the fact > > > > that curr might be deadline as well and already consuming some of > > > > the rq capacity. > > > > > > > > Do you think we should try to take that into account, maybe using > > > > dl_rq->this_bw ? > > > > > > So you're saying that cpudl_find(..., later_mask) could return 1 (w/ > > > best_cpu (cp->elements[0].cpu) in later_mask). > > > > > > And that this best_cpu could be a non-fitting CPU for p. > > > > > > This could happen if cp->free_cpus is empty (no idle CPUs) so we > > > take cpudl_find()'s else path and in case p's deadline < > > > cp->elements[0] deadline. > > > > > > We could condition the 'return 1' on best_cpu fitting p. > > > > > > But should we do this for cpudl_find(..., NULL) calls from > > > check_preempt_equal_dl() as well or will this break GEDF? > > > > So, even by not returning best_cpu, as above, if it doesn't fit p's bw > > requirement, I think we would be breaking GEDF, which however doesn't > > take asym capacities into account. > > Well, gEDF could take asymmetric capacities into account by scheduling > the earliest deadline task on the fastest CPU (and the task with the > second earliest deadline on the second fastest CPU, and so on...) > > But this could cause a lot of unneeded migrations (I tried to discuss > this issue in a previous OSPM presentation). My original approach to > work around this issue was to schedule a task on the slowest core on > which the task can fit (some experiments revealed that this heuristic > can approximate the gEDF behaviour without causing too many > migrations)... But this patch is not included on the current patchset, > and will be proposed later, after the most important patches have been > merged. OK, makes sense to me. And I'm ok also with a 2 steps approach. Asym idle now and asym busy with a later series. Best, Juri