Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp997755ybj; Tue, 5 May 2020 11:07:28 -0700 (PDT) X-Google-Smtp-Source: APiQypJNQae5WuEqkixeS5ViLfqFWtcUcQnd7J4TpC+Ocipw8FQKWAedjSGRqbv0thCBE/r0ECxD X-Received: by 2002:a17:906:e01:: with SMTP id l1mr3945659eji.76.1588702048290; Tue, 05 May 2020 11:07:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588702048; cv=none; d=google.com; s=arc-20160816; b=C4Rj6OAcl2R0CgAKCNDLIU76KTXRCmYi6Js1aj8Rb/uEBK/qTzQljZYeoAwkU3N2U7 0XCzAF32KHeIh5jY0GF9wXg4uxGSQxCOmfs0lh2UXeIPH0FdRDKC1p6dup+xhOtUUNdn GlaqwNK0GhHazan0Rxzu2KI8fcjwfeLjVfcP9NIrlIuTcVBkc4cqJe+2ebtvLzyPin+W qdfbZNSORg8+BEL2qe33Fmx+aoCPg60PdLoU2fYqHLL1sy2NulULmFMzXO+S96A23pBX I+Zs397oynXqvfezDWgaJMucbnuA5o7qxz81cRjb/EUNf21L8oGhNy/8xXuLKHhzQip1 XXDA== 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=JpjmG+n1Up+aGj1ttbht33eLoLysSPeaAOfPwMCA2uE=; b=a5oKSw5dLVS9tV/U8INFOatAi0epYZhvQ1mMHjygskL1U7fUQ1lE++ubvIEgObh4T1 4xtFVL5fGjD0IH/DxFPPNcLmYrd5NoIL/QOwD1d7A+pdlbyejcCKAZCVtWldqsU3sy69 XDKKw/QThSfTp7ENVF+CP/87drjmm7H+/YQsfw6dUTaktY7xNu8+nAGn8GzOjtm645+8 ZBeSTAASFQrXhrR8WRvSUFA93vl+ISPvVS2NApfqE3Yt9u40T0Cgb6w6wuJW1/PCEjLI 9Piyk6Wr+LzSduDFTPuP5arNpOc+TV1xqJBP+2u0+eXuDB9tyE/viXikSdDzo8OAcep1 Lt1A== 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 cy17si1753321edb.84.2020.05.05.11.06.38; Tue, 05 May 2020 11:07:28 -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 S1730517AbgEESCT (ORCPT + 99 others); Tue, 5 May 2020 14:02:19 -0400 Received: from foss.arm.com ([217.140.110.172]:46898 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1730069AbgEESCS (ORCPT ); Tue, 5 May 2020 14:02:18 -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 871F71FB; Tue, 5 May 2020 11:02:12 -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 9B0DF3F305; Tue, 5 May 2020 11:02:09 -0700 (PDT) Subject: Re: [PATCH v2 5/6] sched/deadline: Make DL capacity-aware To: Pavan Kondeti Cc: Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Steven Rostedt , Luca Abeni , Daniel Bristot de Oliveira , Wei Wang , Quentin Perret , Alessio Balsini , Patrick Bellasi , Morten Rasmussen , Valentin Schneider , Qais Yousef , linux-kernel@vger.kernel.org References: <20200427083709.30262-1-dietmar.eggemann@arm.com> <20200427083709.30262-6-dietmar.eggemann@arm.com> <20200430131036.GE19464@codeaurora.org> <20200504035842.GF19464@codeaurora.org> From: Dietmar Eggemann Message-ID: <55fed70f-b64f-36a7-326d-70859bfdd315@arm.com> Date: Tue, 5 May 2020 20:02:00 +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: <20200504035842.GF19464@codeaurora.org> 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 04/05/2020 05:58, Pavan Kondeti wrote: > On Fri, May 01, 2020 at 06:12:07PM +0200, Dietmar Eggemann wrote: >> On 30/04/2020 15:10, Pavan Kondeti wrote: >>> On Mon, Apr 27, 2020 at 10:37:08AM +0200, Dietmar Eggemann wrote: >>>> From: Luca Abeni >> >> [...] >> >>>> @@ -1653,10 +1654,19 @@ select_task_rq_dl(struct task_struct *p, int cpu, int sd_flag, int flags) >>>> * other hand, if it has a shorter deadline, we >>>> * try to make it stay here, it might be important. >>>> */ >>>> - if (unlikely(dl_task(curr)) && >>>> - (curr->nr_cpus_allowed < 2 || >>>> - !dl_entity_preempt(&p->dl, &curr->dl)) && >>>> - (p->nr_cpus_allowed > 1)) { >>>> + select_rq = unlikely(dl_task(curr)) && >>>> + (curr->nr_cpus_allowed < 2 || >>>> + !dl_entity_preempt(&p->dl, &curr->dl)) && >>>> + p->nr_cpus_allowed > 1; >>>> + >>>> + /* >>>> + * Take the capacity of the CPU into account to >>>> + * ensure it fits the requirement of the task. >>>> + */ >>>> + if (static_branch_unlikely(&sched_asym_cpucapacity)) >>>> + select_rq |= !dl_task_fits_capacity(p, cpu); >>>> + >>>> + if (select_rq) { >>>> int target = find_later_rq(p); >>> >>> I see that find_later_rq() checks if the previous CPU is part of >>> later_mask and returns it immediately. So we don't migrate the >>> task in the case where there previous CPU can't fit the task and >>> there are no idle CPUs on which the task can fit. LGTM. >> >> Hope I understand you here. I don't think that [patch 6/6] provides this >> already. >> >> In case 'later_mask' has no fitting CPUs, 'max_cpu' is set in the >> otherwise empty 'later_mask'. But 'max_cpu' is not necessary task_cpu(p). >> >> Example on Juno [L b b L L L] with thread0-0 (big task) >> >> cpudl_find [thread0-0 2117] orig later_mask=0,3-4 later_mask=0 >> find_later_rq [thread0-0 2117] task_cpu=2 later_mask=0 >> >> A tweak could be added favor task_cpu(p) in case it is amongst the CPUs >> with the maximum capacity in cpudl_find() for the !fit case. >> > > You are right. max_cpu can be other than task_cpu(p) in which case we > migrate the task though it won't fit on the new CPU. While introducing > capacity awareness in RT, Quais made the below change to avoid the > migration. We can do something similar here also. > > commit b28bc1e002c2 (sched/rt: Re-instate old behavior in select_task_rq_rt()) I'm not sure something like this is necessary here. With DL capacity awareness we reduce the later_mask returned by cpudl_find() in find_later_rq() to those idle CPUs which can handle p or in case there is none to (the/a) 'non-fitting CPU w/ max capacity'. We just have to favor task_cpu(p) in [patch 6/6] in case it is part of the initial later_mask and among these 'non-fitting CPUs w/ max capacity'. This will make sure that it gets chosen so find_later_rq() returns it before the 'for_each_domain()' loop. And I guess we still want to migrate if there is a non-fitting CPU w/ a higher CPU capacity than task_cpu() (tri-gear). @@ -137,7 +137,8 @@ int cpudl_find(struct cpudl *cp, struct task_struct *p, cap = capacity_orig_of(cpu); - if (cap > max_cap) { + if (cap > max_cap || + (cpu == task_cpu(p) && cap == max_cap)) { max_cap = cap; max_cpu = cpu; In case task_cpu() is not part of later_cpu, the 'max CPU capacity CPU' is returned as 'best_cpu'. [...]