Received: by 2002:a25:23cc:0:0:0:0:0 with SMTP id j195csp1798773ybj; Wed, 6 May 2020 05:39:41 -0700 (PDT) X-Google-Smtp-Source: APiQypIK4TBBzuONX+7WDpxKAoiWMpTgOyHUdGo7K3STdydc3350fbOiqEnWEY22jItTA0RWir32 X-Received: by 2002:a17:906:d10b:: with SMTP id b11mr6884561ejz.62.1588768781108; Wed, 06 May 2020 05:39:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1588768781; cv=none; d=google.com; s=arc-20160816; b=EPxx9U8XfBzQLJgFph/+oXAh9i5ZnDdMtgPQFKU1RjAc2AbbwQp+a8/xEd1tRXYQsq 7kIWxJMYrsRg+hSHT0cAxUAWNEs4QG/qSTcoeYDJm2RjMes/cjuXAWuQ53/J/p61ck6d wfwGjFuqulvair5s1yOjvIsCispb1UIf/jx5E59FVWTYEi28RMZnAoOfojsY+S2xOAay sc7rT458TqVwOFbym6U5RmAVXzDlaIwVNxNAE5TwOZ6egM97JoF6unUrXHpdeaflxh/l IF7TlIHCmswSZVWnnAo8y2iu+RHjlqEsRgODLoZUCpfmNKdx8eu6BnOBdF/9/EFdDzUD D92Q== 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=s1MktsIoJtjuCK1LIHvBtwFHwePnfE+EvLWoNj84r9o=; b=WIeWueUSGA4nTnEwrkevXoiAE+k+5xIeNvBgbGAiu+FLuvnLRVBG3XIkofClW/0lOk 76mCFlqjEYHhxWdbDe/+XG29yzg0c/KX3ifxx1/niPOLOKmya+P8arVLlTRfLi0qEBm8 RsHIsGZZEWOTK/KsZzlvzC4EB7tnJCN1IfkgOY3Q+M/65i9IgFGzIXlWihL0L+0t5Low lKsNqIgCmu5WXqtuBuy9b2mCDdSqyuXM6RzHztdoRH8Fj/CPmGgdNkXeXgmrbE1rZWj8 GHck4kSdIixJM7go51AeZtoOtAdhc8SydX/yFAuarTcskZ1Y+HlJlfaE2m3/dhkJDmMI 5ypg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=TemheLuS; 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 l3si960139edr.46.2020.05.06.05.39.17; Wed, 06 May 2020 05:39:41 -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=TemheLuS; 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 S1728097AbgEFMhr (ORCPT + 99 others); Wed, 6 May 2020 08:37:47 -0400 Received: from us-smtp-2.mimecast.com ([205.139.110.61]:36360 "EHLO us-smtp-delivery-1.mimecast.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1727067AbgEFMhq (ORCPT ); Wed, 6 May 2020 08:37:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1588768665; 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=s1MktsIoJtjuCK1LIHvBtwFHwePnfE+EvLWoNj84r9o=; b=TemheLuScOS/0GLmlAwKqCZccXkeRQanV9t61T+tU5U+Yi/32PEcesUit3bG2FWQEVUkx1 WKIbgbu0FZLvjEbWC/nK1HovZAQHITt4Qib+WEHucDKt17LJc8MHTsKs1y6XlEdNvHjLz+ w6XVeDA5TbijsqGCFXioMCkvGVTPnVA= 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-510-NoBxukqMP_iuMvZq34wtQA-1; Wed, 06 May 2020 08:37:43 -0400 X-MC-Unique: NoBxukqMP_iuMvZq34wtQA-1 Received: by mail-wm1-f70.google.com with SMTP id o26so813436wmh.1 for ; Wed, 06 May 2020 05:37:43 -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=s1MktsIoJtjuCK1LIHvBtwFHwePnfE+EvLWoNj84r9o=; b=MwsG0XjQq16RvAjMSG6feWwI/sICYU6g/FS3wJuKfDQCw1Vm9zum/PRoqsPtZUTS+1 A7iW2e3cfncaVLfTTqRJibhwI5chNExzACAQC9UFJLfXWemYs9r2nfcx5wAnSyvSfyUS BRK4sLxWtnvNFJE/yrf7NDDD2v/LMh4rCeUwcnOHDODVp3cnCgvOjSd5tMnLI4aZDkfp hIsObo0bA1q/sxjKUj4OlL61K69i8LTDyPYvX/UnDe0lHx3G8CjgsW/ppXNByzbuyGRQ YU3BU1oCjglZF49PQ4oNXFI5feF95L31RRXo+rjlf4L4bwnztM/Nbzk4YAYav7uaQPgY doog== X-Gm-Message-State: AGi0PuYNJgYH8VdtMdItAW8eo9kqFozvdH/uQDItZQdw7MzI2lSYllhO fcqI+WggCerCTiBRsR5KegF+DVmQLfUSA61FauefS9VGBsMRtIrUdqNIJwbbrubxAwXCOblkgJA bOFH0c6mNnOh4STWN5CBolCl3 X-Received: by 2002:adf:c7c3:: with SMTP id y3mr9163128wrg.196.1588768662158; Wed, 06 May 2020 05:37:42 -0700 (PDT) X-Received: by 2002:adf:c7c3:: with SMTP id y3mr9163084wrg.196.1588768661793; Wed, 06 May 2020 05:37:41 -0700 (PDT) Received: from localhost.localdomain ([151.29.188.60]) by smtp.gmail.com with ESMTPSA id z1sm2871826wmf.15.2020.05.06.05.37.40 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 06 May 2020 05:37:41 -0700 (PDT) Date: Wed, 6 May 2020 14:37:38 +0200 From: Juri Lelli To: Dietmar Eggemann Cc: Ingo Molnar , Peter Zijlstra , Vincent Guittot , Steven Rostedt , Luca Abeni , 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 v2 3/6] sched/deadline: Add dl_bw_capacity() Message-ID: <20200506123738.GJ17381@localhost.localdomain> References: <20200427083709.30262-1-dietmar.eggemann@arm.com> <20200427083709.30262-4-dietmar.eggemann@arm.com> <23bde551-0d91-4bfe-ce65-40af9fbfdef9@arm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <23bde551-0d91-4bfe-ce65-40af9fbfdef9@arm.com> Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 06/05/20 12:54, Dietmar Eggemann wrote: > On 27/04/2020 10:37, Dietmar Eggemann wrote: > > [...] > > > diff --git a/kernel/sched/deadline.c b/kernel/sched/deadline.c > > index 4ae22bfc37ae..eb23e6921d94 100644 > > --- a/kernel/sched/deadline.c > > +++ b/kernel/sched/deadline.c > > @@ -69,6 +69,25 @@ static inline int dl_bw_cpus(int i) > > > > return cpus; > > } > > + > > +static inline unsigned long dl_bw_capacity(int i) > > +{ > > + struct root_domain *rd = cpu_rq(i)->rd; > > + unsigned long cap; > > + > > + RCU_LOCKDEP_WARN(!rcu_read_lock_sched_held(), > > + "sched RCU must be held"); > > + > > + if (cpumask_subset(rd->span, cpu_active_mask)) > > + return rd->sum_cpu_capacity; > > + > > + cap = 0; > > + > > + for_each_cpu_and(i, rd->span, cpu_active_mask) > > + cap += capacity_orig_of(i); > > + > > + return cap; > > +} > > There is an issue w/ excl. cpusets and cpuset.sched_load_balance=0. The > latter is needed to demonstrate the problem since DL task affinity can't > be altered. > > A CPU in such a cpuset has its rq attached to def_root_domain which does > not have its 'sum_cpu_capacity' properly set. Hummm, but if sched_load_balance is disabled it means that we've now got a subset of CPUs which (from a DL AC pow) are partitioned. So, I'd tend to say that we actually want to check new tasks bw requirement against the available bandwidth of the particular CPU they happen to be running (and will continue to run) when setscheduler is called. If then load balance is enabled again, AC check we did above should still be valid for all tasks admitted in the meantime, no?