Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp865326ybz; Wed, 29 Apr 2020 10:43:54 -0700 (PDT) X-Google-Smtp-Source: APiQypIxnYdbtYW7skQsLhqVXuYMNSsljjhZaMpkiNvgjnrd0dvRa37y1m1fnKVKPtzGToi0R6y6 X-Received: by 2002:a17:906:400a:: with SMTP id v10mr3635727ejj.300.1588182234607; Wed, 29 Apr 2020 10:43:54 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588182234; cv=none; d=google.com; s=arc-20160816; b=B3pWewMWddCfSIyQ0CH8FSht4TSlHkqc6sGnmuBlbO9R77ThNq7H7ADUWh774nimfg zGfb7w3/Y5hKqtolH30s6n7NsfHYDqymAVJWZ1REHEfsKwPYTuvnB4ZjH6DnTQ91eRdj Ngv32Phb6TQSvnGMz40FVulk462ZAcSEE++Vc8j1wy+N14CytU7p/dXqGB8eYPp1l+uP Ff/5UNAMlGhrXE2LxoTzKt+H7s0pUnXoPdAj+RPmQLx9qXwvLEB2FLrovYHDjin6pEcO fIpRvmJM66STIxBWCfb/ex79Dga13rP/9AXsL5+8gLFs80xlFzl7v1pQ8y1ufyxKvTbH aZjA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=lh8DbZb/9r3pIDl/jzffyw+UbPQBi8+3Xk5vCZss59w=; b=D9rGGcGm9p19AP0a/NmrevPwp2+UUvc7vHz1cmXsQBIQvaow5h0i915dH9rM0+OYOF CuOFpEnDYERpvsPIj0k0y6FCVF92XEp6l5FYfBO/edvpZzvIUDKFJ/h+1Pcho0jXLB/Z 6KZb/CAnz1HmYtRqbYqSTgkZRn8MZDTHpOKswBa8RSqyrS0O/Dg08Zw49EavImEE2LvT 6gJ8cib/OzyTwf27WubEdDkKVeGcKr1ysDcdqV5aByRbLEZMNvYHlXtLZdlYNmjiAPNJ q9zwVmBRPxnsnl5ztLMrn3LvHO3ZvSfWfGwRCvakn0Lm06q0ABdy9ohHYQDQTXEmOekr yyWg== ARC-Authentication-Results: i=1; mx.google.com; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i26si4270998ejg.474.2020.04.29.10.43.31; Wed, 29 Apr 2020 10:43:54 -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; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726530AbgD2Rjz (ORCPT + 99 others); Wed, 29 Apr 2020 13:39:55 -0400 Received: from foss.arm.com ([217.140.110.172]:42940 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726423AbgD2Rjz (ORCPT ); Wed, 29 Apr 2020 13:39:55 -0400 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.121.207.14]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 295241045; Wed, 29 Apr 2020 10:39:54 -0700 (PDT) Received: from [192.168.0.7] (unknown [172.31.20.19]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id ADD6A3F73D; Wed, 29 Apr 2020 10:39:51 -0700 (PDT) Subject: Re: [PATCH v2 6/6] sched/deadline: Implement fallback mechanism for !fit case To: luca abeni , Juri Lelli Cc: 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 References: <20200427083709.30262-1-dietmar.eggemann@arm.com> <20200427083709.30262-7-dietmar.eggemann@arm.com> <20200427133438.GA6469@localhost.localdomain> <20200427161715.3dd3a148@nowhere> From: Dietmar Eggemann Message-ID: <57e4846a-4e54-5450-8167-768f021250f7@arm.com> Date: Wed, 29 Apr 2020 19:39:50 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20200427161715.3dd3a148@nowhere> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 27/04/2020 16:17, luca abeni wrote: > Hi Juri, > > On Mon, 27 Apr 2020 15:34:38 +0200 > Juri Lelli wrote: > >> Hi, >> >> On 27/04/20 10:37, Dietmar Eggemann wrote: >>> From: Luca Abeni >>> >>> When a task has a runtime that cannot be served within the >>> scheduling deadline by any of the idle CPU (later_mask) the task is >>> doomed to miss its deadline. >>> >>> This can happen since the SCHED_DEADLINE admission control >>> guarantees only bounded tardiness and not the hard respect of all >>> deadlines. In this case try to select the idle CPU with the largest >>> CPU capacity to minimize tardiness. >>> >>> Signed-off-by: Luca Abeni >>> Signed-off-by: Dietmar Eggemann > [...] >>> - if (!cpumask_empty(later_mask)) >>> - return 1; >>> + if (cpumask_empty(later_mask)) >>> + cpumask_set_cpu(max_cpu, later_mask); >> >> Think we touched upon this during v1 review, but I'm (still?) >> wondering if we can do a little better, still considering only free >> cpus. >> >> Can't we get into a situation that some of the (once free) big cpus >> have been occupied by small tasks and now a big task enters the >> system and it only finds small cpus available, were it could have fit >> into bigs if small tasks were put onto small cpus? >> >> I.e., shouldn't we always try to best fit among free cpus? > > Yes; there was an additional patch that tried schedule each task on the > slowest core where it can fit, to address this issue. > But I think it will go in a second round of patches. Yes, we can run into this situation in DL, but also in CFS or RT. IMHO, this patch is aligned with the Capacity Awareness implementation in CFS and RT. Capacity Awareness so far is 'find a CPU which fits the requirement of the task (Req)'. It's not (yet) find the best CPU. CFS - select_idle_capacity() -> task_fits_capacity() Req: util(p) * 1.25 < capacity_of(cpu) RT - select_task_rq_rt(), cpupri_find_fitness() -> rt_task_fits_capacity() Req: uclamp_eff_value(p) <= capacity_orig_of(cpu) DL - select_task_rq_dl(), cpudl_find() -> dl_task_fits_capacity() Req: dl_runtime(p)/dl_deadline(p) * 1024 <= capacity_orig_of(cpu) There has to be an "idle" (from the viewpoint of the task) CPU available with a fitting capacity. Otherwise a fallback mechanism applies. CFS - best capacity handling in select_idle_capacity(). RT - Non-fitting lowest mask DL - This patch You did spot the rt-app 'delay' for the small tasks in the test case ;-)