Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp4166158pxu; Mon, 21 Dec 2020 05:56:25 -0800 (PST) X-Google-Smtp-Source: ABdhPJylKqs6GmEuyDCp8zFUI7xxYn4RAF0eoQU3J+EK9mlqU5r2esjxAoqdRTFWWPhXWRFhlMTE X-Received: by 2002:aa7:c603:: with SMTP id h3mr11351648edq.254.1608558984903; Mon, 21 Dec 2020 05:56:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608558984; cv=none; d=google.com; s=arc-20160816; b=vF/3xXKq3RhGVZyKCR59GQT7YcwVGsyShiJ42IiTrSAODuyfDzbPC2ZYV/WoyrqUdS j2SlGrvT79A9z6Yue5sfzQeFzzgWmUnWhyHgLBREU0HvfizU8MJeEX6YKwlGglzi98dn xxj4hyBV5xpzln3u7gFdSD3GZ8D16TSyPrGls0P2fdbwZw75ciBfbB7GTaX/zKZieP8a yN+H4ILM3SQMIae7wXvmZowSyLfHLPlURyANyveM2wDVFBiVDZIWYzp/xyvg8fMKVgVj VOtYrVfiIwg2ahb5goylcU6cEmlIctHPlSqS4NJnhXh1yuDqfZZiBadPDwT0Djv6RiYv 8vdg== 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=tqdgzu8ZdS+wRMbiy2sJKtxbNHYalYUoKqMAMzdAGa8=; b=zx1DVho2FiF8cttsdMSemjz4OEmfv8U8UgLtw5LqID85hMvtQgpUVQ/jae7pti13RK /bxbd6wtMguTzUjpCOHKKBDsc0I2vInvAfzE4D8XT777L0t6UKtuYloTRnvNVXo8CzhA sUXRvKfSFe1oNQqLSRUQUT0RuTX+TjUde9/R7edwflqcl5we0vL9LFSgFgWSUqbXF+lK Lckq1XOeqRD0c2+3Qy+2TpeyXe7qweEbVLxdHsphPV26lhmUAahm3PV/S8RbiFS4q8HE kfXyOlelvIh3mRl4/mJpVn+dyaXtz4QKKLiQF/DBPMsM++QgTf+ZlNcL3lnQiPCmnwt0 7Blg== 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 m6si10134786edr.532.2020.12.21.05.56.02; Mon, 21 Dec 2020 05:56:24 -0800 (PST) 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 S1727013AbgLUNyn convert rfc822-to-8bit (ORCPT + 99 others); Mon, 21 Dec 2020 08:54:43 -0500 Received: from out30-43.freemail.mail.aliyun.com ([115.124.30.43]:57742 "EHLO out30-43.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726612AbgLUNym (ORCPT ); Mon, 21 Dec 2020 08:54:42 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R831e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04426;MF=changhuaixin@linux.alibaba.com;NM=1;PH=DS;RN=15;SR=0;TI=SMTPD_---0UJJwiKU_1608558831; Received: from 192.168.3.8(mailfrom:changhuaixin@linux.alibaba.com fp:SMTPD_---0UJJwiKU_1608558831) by smtp.aliyun-inc.com(127.0.0.1); Mon, 21 Dec 2020 21:53:52 +0800 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.11\)) Subject: Re: [PATCH 1/4] sched/fair: Introduce primitives for CFS bandwidth burst From: changhuaixin In-Reply-To: <20201217133656.GX3040@hirez.programming.kicks-ass.net> Date: Mon, 21 Dec 2020 21:53:51 +0800 Cc: changhuaixin , linux-kernel@vger.kernel.org, bsegall@google.com, dietmar.eggemann@arm.com, juri.lelli@redhat.com, mgorman@suse.de, mingo@redhat.com, pauld@redhead.com, pjt@google.com, rostedt@goodmis.org, vincent.guittot@linaro.org, khlebnikov@yandex-team.ru, xiyou.wangcong@gmail.com, shanpeic@linux.alibaba.com Content-Transfer-Encoding: 8BIT Message-Id: References: <20201217074620.58338-1-changhuaixin@linux.alibaba.com> <20201217074620.58338-2-changhuaixin@linux.alibaba.com> <20201217133656.GX3040@hirez.programming.kicks-ass.net> To: Peter Zijlstra X-Mailer: Apple Mail (2.3445.104.11) Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > On Dec 17, 2020, at 9:36 PM, Peter Zijlstra wrote: > > On Thu, Dec 17, 2020 at 03:46:17PM +0800, Huaixin Chang wrote: >> In this patch, we introduce the notion of CFS bandwidth burst. Unused >> "quota" from pervious "periods" might be accumulated and used in the >> following "periods". The maximum amount of accumulated bandwidth is >> bounded by "burst". And the maximun amount of CPU a group can consume in >> a given period is "buffer" which is equivalent to "quota" + "burst in >> case that this group has done enough accumulation. > > Oh man, Juri, wasn't there a paper about statistical bandwidth > accounting somewhere? Where, if you replace every utilization by a > statistical variable, the end result is still useful? > > That is, instead of something like; \Sum u_i <= 1, you get something > like: \Sum {avg(u),var(u)}_i <= {1, sqrt(\Sum var_i^2)} and you can > still proof bounded tardiness etc.. (assuming a gaussian distribution). > > The proposed seems close to that, but not quite, and I'm afraid it's not > quite strong enough to still provide any guarantees. After reading some papers on statistical bandwidth sharing, it occurs to me that statistical bandwidth sharing is about the way bandwidth is shared between competitors. I wonder if the paper you mentioned was "Insensitivity results in statistical bandwidth sharing" or some paper referenced, which showed the end result is insensitive to maybe the distribution or the arrival pattern. I am sorry that I cannot prove using statistical bandwidth sharing theory now. However, I wonder if it is more acceptable to put rate-based cfsb after share fairness, because the input stream of cfsb account is the output stream of fairness. And that is in contrast with what statistical bandwidth sharing does, in which fairness is used to share bandwidth upon the output stream of rate-based control. In this way, maybe guarantees can be provided by share fairness, and cfsb may use a larger buffer to allow more jitters. A buffer, which is several times of quota, is able to handle large bursts, and throttle threads soon when overloaded. The present cfsb, however, has to be configured several times larger to handle jitters, which is ineffective and does not provide the designed rate-based control.