Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp114092pxf; Wed, 17 Mar 2021 00:17:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyw+lC5ka06VpNJKfPgS0SNZq0QZEcZlWFeOkET0cIEI80nftCc+KHzN28YaZQghIVH8+BT X-Received: by 2002:a17:907:2716:: with SMTP id w22mr33831888ejk.328.1615965472176; Wed, 17 Mar 2021 00:17:52 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1615965472; cv=none; d=google.com; s=arc-20160816; b=WrxNsJ+Nl9RAZ3eMB1b9a+kgq1pdh/BzxfpVch9REIyIB3LjwzcqPuO+1h1G/J8GGt ioZRNsVyHIVSngb6MGLatXQkO2mvvC8L5F/xVVew4VXmc6LXwFc9bvTD52c2j1VxHqZt yaa+lqLuunJTQr/DYml65cMvy81xs7jU4kIgoOyrzf0YMsenyuLNPYbBUG04VQ/hmrmz MOxbF2+DCq0lgpyvDYlHtK4eF2Ct2C4PrtTK7AsTO/W3OktKt9O8V+QGm9SulB/IPI8O MxAT7FKp4cKzg0kYgkB/fxbbjj88+9Y5b8UHjpESBoTtCALU1OVrh/unlox4rRezFaW7 owZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:to:references:message-id :content-transfer-encoding:cc:date:in-reply-to:from:subject :mime-version; bh=xHw9Wzl8oBx9xNmeqSsaCtkGCc/CRFMCgJV3/4bs24I=; b=a/7RknRnG2BIvLEs9y+I6EVL/NiGrxaoduQ3I5IVfHrzadO/xdXCUA08cIl/9spCNA rMUx0uKV4gkyILAC6o9dmkO8vP/BtNpFam/reRUqYCWlF1TeYUiM7jI4DzRlrMKSuU+w q8xcTahDDl4IRuNYH25Wy98l7UGi8MPPWLzQrRRnXoiX4rdG5botU5+6cTlyb4EjZVKr OO2K/KC0ipu3eIRKuCKSORyLblZB0RMu+5iQ2/94NOnS3uA+hA2mLJGSoDmJpY36UYnm zBrTgkRbKkw3AWx5xsCQNvfwnS3Z1r5tHGdsZOF/JRdz83uoqh3VSy5BCmKFBPyjMePe 2wtA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id i20si15204063edq.582.2021.03.17.00.17.30; Wed, 17 Mar 2021 00:17:52 -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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229675AbhCQHOh convert rfc822-to-8bit (ORCPT + 99 others); Wed, 17 Mar 2021 03:14:37 -0400 Received: from out30-45.freemail.mail.aliyun.com ([115.124.30.45]:55896 "EHLO out30-45.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229550AbhCQHO0 (ORCPT ); Wed, 17 Mar 2021 03:14:26 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R151e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=alimailimapcm10staff010182156082;MF=changhuaixin@linux.alibaba.com;NM=1;PH=DS;RN=18;SR=0;TI=SMTPD_---0USESlcv_1615965261; Received: from 30.240.101.46(mailfrom:changhuaixin@linux.alibaba.com fp:SMTPD_---0USESlcv_1615965261) by smtp.aliyun-inc.com(127.0.0.1); Wed, 17 Mar 2021 15:14:22 +0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [PATCH v4 1/4] sched/fair: Introduce primitives for CFS bandwidth burst From: changhuaixin In-Reply-To: Date: Wed, 17 Mar 2021 15:16:18 +0800 Cc: changhuaixin , Benjamin Segall , dietmar.eggemann@arm.com, juri.lelli@redhat.com, khlebnikov@yandex-team.ru, open list , mgorman@suse.de, mingo@redhat.com, Odin Ugedal , Odin Ugedal , pauld@redhead.com, Paul Turner , rostedt@goodmis.org, Shanpei Chen , Tejun Heo , Vincent Guittot , xiyou.wangcong@gmail.com Content-Transfer-Encoding: 8BIT Message-Id: References: <20210316044931.39733-1-changhuaixin@linux.alibaba.com> <20210316044931.39733-2-changhuaixin@linux.alibaba.com> To: Peter Zijlstra X-Mailer: Apple Mail (2.3445.104.11) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Mar 16, 2021, at 5:54 PM, Peter Zijlstra wrote: > > On Tue, Mar 16, 2021 at 12:49:28PM +0800, Huaixin Chang wrote: >> @@ -8982,6 +8983,12 @@ static int tg_set_cfs_bandwidth(struct task_group *tg, u64 period, u64 quota) >> if (quota != RUNTIME_INF && quota > max_cfs_runtime) >> return -EINVAL; >> >> + /* >> + * Bound burst to defend burst against overflow during bandwidth shift. >> + */ >> + if (burst > max_cfs_runtime) >> + return -EINVAL; > > Why do you allow such a large burst? I would expect something like: > > if (burst > quote) > return -EINVAL; > > That limits the variance in the system. Allowing super long bursts seems > to defeat the entire purpose of bandwidth control. I understand your concern. Surely large burst value might allow super long bursts thus preventing bandwidth control entirely for a long time. However, I am afraid it is hard to decide what the maximum burst should be from the bandwidth control mechanism itself. Allowing some burst to the maximum of quota is helpful, but not enough. There are cases where workloads are bursty that they need many times more than quota in a single period. In such cases, limiting burst to the maximum of quota fails to meet the needs. Thus, I wonder whether is it acceptable to leave the maximum burst to users. If the desired behavior is to allow some burst, configure burst accordingly. If that is causing variance, use share or other fairness mechanism. And if fairness mechanism still fails to coordinate, do not use burst maybe. In this way, cfs_b->buffer can be removed while cfs_b->max_overrun is still needed maybe.