Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp766514ybb; Wed, 8 Apr 2020 09:28:37 -0700 (PDT) X-Google-Smtp-Source: APiQypI5ql2/x4FmRx+EqXDnpe+cGAqpOlmrRLXGOyZJOhlngBpycH5M4elo/pCbPWgZwBPhbeiz X-Received: by 2002:aca:b441:: with SMTP id d62mr3154393oif.107.1586363317672; Wed, 08 Apr 2020 09:28:37 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586363317; cv=none; d=google.com; s=arc-20160816; b=fDlekNo8zUy9DcROOAWK2yAVbHEt2bvhvP/NcEh7apiC8wGvUrstIMcu/AugcyKhgG mrDxWyGcTZH/d/894dYi/zrpLjPxUZNKAEPFUlCAkseiL81xUduSALfSfQwBHXIiCt53 shoMz356MGt6wZb25BkB+qUs9lOH7IMXJ9gya5ku1TmItxDudVBxm+N0RPmbk/RoCmpD 5aJm1L2fGM1O4eguW8BpQ4Miah0eYls8wshZwg9MN06gPJqYjX0nZC7b2gLF3ZVywVN3 86u7z4hwHms0Nl30TUVuaiPCyB4GDZLlsOOtNKnpwDhVnHwdFnnLq0TNBjAVEQ7HRDAl r7Ag== 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=JeyJWVKVJZ2IxCRqPamNKNCQv58PtEogZflTxnSHK48=; b=eXzdzjjXr81btU+dNRh1PMfe//AJRGyxTevpY8aQNi9irIZZW4QCthyVBqT9K6+vH/ SMq7KbDJ1Fi/y7K/pRyuNkwuA+v9qvy7M9FPD7Paob/z3KLlWbu4ugfLueRT9gKRC3SB StcP0xlws/B07FC2L3/ZZeqBNnIcRRjyD+aOioZ8u21UTNTVlMHBbARumis7uDS9b0vT +KTj5yisKydqSqr3KhIvEPKqvQbeDfuRnFQExD6dEjzAVVHxr0p3jww3yLWySd6tlKJh jjVDpCos1ZBs2bAOFdcFa+OiMU5Z0zZtD3JS9zQfiBvrGg0yHEiq57OR7NEW9EXxDHVj tb+Q== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id x6si2738191oto.92.2020.04.08.09.28.24; Wed, 08 Apr 2020 09:28:37 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728731AbgDHOXT (ORCPT + 99 others); Wed, 8 Apr 2020 10:23:19 -0400 Received: from foss.arm.com ([217.140.110.172]:39236 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727070AbgDHOXT (ORCPT ); Wed, 8 Apr 2020 10:23:19 -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 98F3D30E; Wed, 8 Apr 2020 07:23:18 -0700 (PDT) Received: from e107158-lin.cambridge.arm.com (e107158-lin.cambridge.arm.com [10.1.195.21]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 9E25F3F68F; Wed, 8 Apr 2020 07:23:16 -0700 (PDT) Date: Wed, 8 Apr 2020 15:23:14 +0100 From: Qais Yousef To: luca abeni Cc: Valentin Schneider , Dietmar Eggemann , Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Steven Rostedt , Daniel Bristot de Oliveira , Wei Wang , Quentin Perret , Alessio Balsini , Pavan Kondeti , Patrick Bellasi , Morten Rasmussen , linux-kernel@vger.kernel.org Subject: Re: [PATCH 2/4] sched/deadline: Improve admission control for asymmetric CPU capacities Message-ID: <20200408142313.j6yfv6s3i5pzs5wv@e107158-lin.cambridge.arm.com> References: <20200408095012.3819-1-dietmar.eggemann@arm.com> <20200408095012.3819-3-dietmar.eggemann@arm.com> <20200408153032.447e098d@nowhere> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20200408153032.447e098d@nowhere> User-Agent: NeoMutt/20171215 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 04/08/20 15:30, luca abeni wrote: > Hi Valentin, > > On Wed, 08 Apr 2020 11:42:14 +0100 > Valentin Schneider wrote: > > > On 08/04/20 10:50, Dietmar Eggemann wrote: > > > +++ b/kernel/sched/sched.h > > > @@ -304,11 +304,14 @@ void __dl_add(struct dl_bw *dl_b, u64 tsk_bw, > > > int cpus) __dl_update(dl_b, -((s32)tsk_bw / cpus)); > > > } > > > > > > +static inline unsigned long rd_capacity(int cpu); > > > + > > > static inline > > > -bool __dl_overflow(struct dl_bw *dl_b, int cpus, u64 old_bw, u64 > > > new_bw) +bool __dl_overflow(struct dl_bw *dl_b, int cpu, u64 > > > old_bw, u64 new_bw) { > > > return dl_b->bw != -1 && > > > - dl_b->bw * cpus < dl_b->total_bw - old_bw + new_bw; > > > + cap_scale(dl_b->bw, rd_capacity(cpu)) < > > > + dl_b->total_bw - old_bw + new_bw; > > > } > > > > > > > I don't think this is strictly equivalent to what we have now for the > > SMP case. 'cpus' used to come from dl_bw_cpus(), which is an ugly way > > of writing > > > > cpumask_weight(rd->span AND cpu_active_mask); > > > > The rd->cpu_capacity_orig field you added gets set once per domain > > rebuild, so it also happens in sched_cpu_(de)activate() but is > > separate from touching cpu_active_mask. AFAICT this mean we can > > observe a CPU as !active but still see its capacity_orig accounted in > > a root_domain. > > Sorry, I suspect this is my fault, because the bug comes from my > original patch. > When I wrote the original code, I believed that when a CPU is > deactivated it is also removed from its root domain. > > I now see that I was wrong. Shouldn't rd->online be equivalent to (rd->span & cpu-active_mask)? -- Qais Yousef