Received: by 2002:a05:6a10:6744:0:0:0:0 with SMTP id w4csp2429914pxu; Sun, 18 Oct 2020 02:09:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxrWWgylN/0BDLY9Y4JD5xUxIgPpM2GcJxCuKCLY6ld4vNSToGhURWZE70HztsEvQlbTY3v X-Received: by 2002:a17:906:fb0d:: with SMTP id lz13mr11902747ejb.227.1603012180896; Sun, 18 Oct 2020 02:09:40 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1603012180; cv=none; d=google.com; s=arc-20160816; b=PlJfkNn5Cjpe2aGW83vdj6NMSFYi5Uobh2aRVsPJbp2/fMJiuxG46uo9bngyrUj8Cq CBscXiM33N6VnBHyWcshOHRyU+scGcL8pRcjr3VPE6Gcsj9LtHUZTTo91AbL3vTndqXR U4Bfj2y8X3VJBGqv9HzUOXqmxSDyJlujgHQcLmzDwyOxOcZ+Xo474Iy+Ulwifo4F5s87 Md+R617ZxmXLbVfCzlOSA4vKAJ2W0BKoQIkh9urZJvT6i/fbXZwECODE4+uR/ttpGRLG baL0iKua3IIBU2xmdVGRU27QQWhKQcU6by2wOv8KNpmA4xDujmk2Cnn26xBf4NeThWJP Jgsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:content-language :in-reply-to:mime-version:user-agent:date:message-id:from:references :cc:to:subject:dkim-signature; bh=/lBT3OTVFipCR4zZkozYGoBkHRhMOkVqglG62jYQatI=; b=XU1hXEHpnH83opUZWbmWv6SbeHBu16GkGqUTqFXz0799vvI38Lihh4PV5IaqhvWQE9 8TFY2xJZkC+BNK+UhXi+bMQNjAwkXHaEdImj6xIXQ9IdCh32Z+zhEIYRN5cr/cqjezZk wWPF0TcT5R/Mf0ihBJnWoGj0ipDXK+R5o2R92j6kaRrvEBC0Q+CpGMsl0liWqNWsYCzK x3dXlyOG4yIH3AR+4J+lC7qDmFUQ5bh0xBTnJVBGO07ugmhTLOSUMzwxKxfZ7vpc+FAS Vph8jPJzv4eRQw0pO1+4W4WAvGY9qPBj4S+32s0WVOnjj4nZIzAYpTnpOz6Sprj54Ka9 11dA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b="M/AVa9X8"; 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 b59si5209394edf.117.2020.10.18.02.09.17; Sun, 18 Oct 2020 02:09:40 -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="M/AVa9X8"; 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 S1726285AbgJRI10 (ORCPT + 99 others); Sun, 18 Oct 2020 04:27:26 -0400 Received: from us-smtp-delivery-124.mimecast.com ([63.128.21.124]:21760 "EHLO us-smtp-delivery-124.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725468AbgJRI1Z (ORCPT ); Sun, 18 Oct 2020 04:27:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1603009643; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=/lBT3OTVFipCR4zZkozYGoBkHRhMOkVqglG62jYQatI=; b=M/AVa9X82wGv/azCMR4i4Z9lYRu2IPNUWDk69eQ41cN++uXodHxa8NImvOvzdc8K8rqZ7c /kkrCct7dRRjfrImyw7HbOMZL2gBksFXISsyVPRgFguQ+dPoobp4XVjER7H2cVl3arfU44 R+zi395bYCD/vMKjbltI2feMK2tXh2E= Received: from mail-wr1-f70.google.com (mail-wr1-f70.google.com [209.85.221.70]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-532-lIRewBZLOUi2dwr3LdQXrA-1; Sun, 18 Oct 2020 04:27:21 -0400 X-MC-Unique: lIRewBZLOUi2dwr3LdQXrA-1 Received: by mail-wr1-f70.google.com with SMTP id f11so5887081wro.15 for ; Sun, 18 Oct 2020 01:27:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=/lBT3OTVFipCR4zZkozYGoBkHRhMOkVqglG62jYQatI=; b=F1PNaJxleM1EmLTZRA870VTsjCousjeEpgplQoky/ru0rnlIJ0ddxbm1Hp8DTZeVLT EjrePvi57TyVmlz0HkSO1t43Ykasxzbz+eSvaJZaATBQoKf3+r/C9Z8q89ZWr9rMyJAs yWgXBKIh1hmFY2j8CVKTI9lCXEZ6t31L/wkq+XZ19jSxOGHYm/vCl6eUsr2c1LA3FPWD NjEmFgnvTP7z0vZpjvYVmwGkb5TH1sXMab6nxl41RvUFF+Z3DTCnOJVKYQevsZKWO8sb qTx2ZZ5X3E/69aifN/ITHnrf/AxaFd/ZiEV+dF54+RjWqVLs+M4BoujGLXO/ciPA4XAd jLYA== X-Gm-Message-State: AOAM533zzY2oerOL1us3nQbG9jUEyy6AYOkxuSg6x9Cey5kXkyh0aQp4 /JXGSQO3BPEI11QtarpH9aA7xONXnsUbWeZlXPmDe4JjUQli6MP/7SQTj6ky6KryHDdE0YPCIop O+/W0kDNwvyYhivjMlvYloIhs X-Received: by 2002:adf:e9c6:: with SMTP id l6mr13779086wrn.257.1603009640141; Sun, 18 Oct 2020 01:27:20 -0700 (PDT) X-Received: by 2002:adf:e9c6:: with SMTP id l6mr13779058wrn.257.1603009639883; Sun, 18 Oct 2020 01:27:19 -0700 (PDT) Received: from x1.bristot.me (host-79-33-206-95.retail.telecomitalia.it. [79.33.206.95]) by smtp.gmail.com with ESMTPSA id u202sm11287729wmu.23.2020.10.18.01.27.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 18 Oct 2020 01:27:19 -0700 (PDT) Subject: Re: [PATCH v6 0/2] sched/deadline: Fix and optimize sched_dl_global_validate() To: Juri Lelli , Peng Liu Cc: linux-kernel@vger.kernel.org, mingo@redhat.com, peterz@infradead.org, vincent.guittot@linaro.org, dietmar.eggemann@arm.com, rostedt@goodmis.org, bsegall@google.com, mgorman@suse.de, valentin.schneider@arm.com, raistlin@linux.it References: <20201014133247.GC219214@localhost.localdomain> From: Daniel Bristot de Oliveira Message-ID: <5ce38799-f7cd-6dcb-3e10-5e4767510094@redhat.com> Date: Sun, 18 Oct 2020 10:27:18 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1 MIME-Version: 1.0 In-Reply-To: <20201014133247.GC219214@localhost.localdomain> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, On 10/14/20 3:32 PM, Juri Lelli wrote: > Hi, > > On 08/10/20 23:47, Peng Liu wrote: >> When change global rt bandwidth, we check to make sure that new >> settings could accommodate the allocated dl bandwidth. >> >> Under SMP, the dl_bw is on a per root domain basis, currently we check >> and update the new settings one cpu by one cpu, but not in the unit of >> root domain, which is either overdoing or error. >> >> patch 1 removed the superfluous checking and updating >> patch 2 fixed the error validation >> >> For details, please see the corresponding patch. >> >> ---------------- >> v6 <-- v5: >> - no functional changes, just revert visit_gen back to u64; >> >> v5 <-- v4: >> - no functional changes, just split the v4 single patch to two to >> obey the "one patch do only one thing" rule; >> - turn root_domain::visit_gen from u64 to u32; >> both suggested by Juri. >> - refine changelog; >> >> v4 <-- v3: >> - refine changelog; >> - eliminate the ugly #ifdef guys with Peter's method; >> >> v3 <-- v2: >> - fix build error for !CONFIG_SMP, reported by kernel test robot; >> >> v2 <-- v1: >> - replace cpumask_weight(cpu_rq(cpu)->rd->span) with dl_bw_cpus(cpu), >> suggested by Juri; >> >> Peng Liu (2): >> sched/deadline: Optimize sched_dl_global_validate() >> sched/deadline: Fix sched_dl_global_validate() >> >> kernel/sched/deadline.c | 44 +++++++++++++++++++++++++++-------- >> kernel/sched/sched.h | 51 ++++++++++++++++++++++------------------- >> kernel/sched/topology.c | 1 + >> 3 files changed, 63 insertions(+), 33 deletions(-) > > These look now good to me. Thanks a lot! > > Acked-by: Juri Lelli I just found a minor thing in a comment: "It's *monotonously* increasing." I tried to find the usage of "monotonously increasing" for monotonic functions, and I did not find it. The (as least most used) term is "monotonically," so the sentence would be like "It is a monotonically increasing value." But it is just a minor thing. Anyways: Reviewed-by: Daniel Bristot de Oliveira Thanks! -- Daniel