Received: by 2002:a05:6a10:9848:0:0:0:0 with SMTP id x8csp140667pxf; Wed, 17 Mar 2021 01:11:19 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzF2ZDO7+qWPniKg2KxyKby6Yl9q/jQSIsleqgnKVnnodPfOPyD/EbVuNB0Jn971zUj98zo X-Received: by 2002:a17:906:d114:: with SMTP id b20mr32899151ejz.449.1615968679530; Wed, 17 Mar 2021 01:11:19 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1615968679; cv=none; d=google.com; s=arc-20160816; b=yHDqAov53QgPtdkB59Jx3vdWxWwraVMOJ9+eVIj2tu+37MX/NSe6k7WwezPYawwpgh +LUDnd3YhUA6uQPoH+xTCFr9OWe7xQMym2uUhll2tqnursrlT9FrNHzQeZFbs5DHcdPr N9u7h9+pWvGiZWbaCqL/gYSIq5pVGtQb/p/o9MSfnwUaZIJBXBpBntwRR108DkEamfGA K4nBjk1zjxEvHHG3HNj7bsnxzJUjM0QuACoV3gqa1KvWG93mYo23kYqbtNL8lUb1r59n pURn1gHwUlEvTXb28qFSjENddOju03VRdfyS455WpZyhxcSyagUD2P8zzABBNivXzY2b zGOQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:dkim-signature; bh=D3q4uZIDgb68GSwlm454Rhapno1E10IoZume3/wE36s=; b=x06SxWwlojGVh8BE84fXbvFxnygjzB5q/s34YcYeM1A097XBLmVAm0E7CloXQz0bCy QS6PwChj49wTAtCD9uOjZ3I7PaO0LtJYtxaqJCTw+MHRXCWgfyvyeHJIa/NyEpP5mhGB wIkBS2GUFH/vZJ6e+Ga7WDKKU+2P5qLVQR/jaGkcdnmm4QcoboDnRk+be68Rkr1yDcd/ 3qbtiWcIOx0Zud1pJx7nkFYFjhHzCHihjcyST+ldGUpbOGu3GLM7LqqNyterxMEXEyye L1JD+YqIDjLOlaF77pYEfTNqVocETaN1w4iUMG/K6S1tHm4FK+EDlyH7S2eIxIpQgb9C y44A== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@infradead.org header.s=casper.20170209 header.b=OjugeP+a; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id t18si15367791ejj.437.2021.03.17.01.10.56; Wed, 17 Mar 2021 01:11:19 -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=@infradead.org header.s=casper.20170209 header.b=OjugeP+a; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229505AbhCQIIA (ORCPT + 99 others); Wed, 17 Mar 2021 04:08:00 -0400 Received: from casper.infradead.org ([90.155.50.34]:50172 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229512AbhCQIHZ (ORCPT ); Wed, 17 Mar 2021 04:07:25 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=casper.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description; bh=D3q4uZIDgb68GSwlm454Rhapno1E10IoZume3/wE36s=; b=OjugeP+axRk/DyZ+Xn2c9QouKf os2/3A3d1KS5D9Y+Pt2NdwUKgRotkjLAxGWq8GD8G4O/+hd5k6yaOrkP5vInMMWDPLJx5qUmglUoK /QLiY7nzYZK3g9o4sqSdkCynWthXd3ZR9sLAwlPnvBhuWup1Gkf2PMYUvN0t1ga6yEULJpUQvfKZj IHctHg23L6C75+sUAfVEEYoQc8mhe58pjxsbNusbDw8HlHGD09U/TcQg9Avrbc0MzgUxszG/OdZMI NjRfLWztjlQ2aTNulNWnLmFCqobHoEHkT/58iwMsC49kOiwDV4rx/H2l+1fHgSiX1yc1hVhKrB+xi 7gZLgllQ==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=noisy.programming.kicks-ass.net) by casper.infradead.org with esmtpsa (Exim 4.94 #2 (Red Hat Linux)) id 1lMRCO-001FQb-3Q; Wed, 17 Mar 2021 08:06:38 +0000 Received: from hirez.programming.kicks-ass.net (hirez.programming.kicks-ass.net [192.168.1.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by noisy.programming.kicks-ass.net (Postfix) with ESMTPS id 59A5C301324; Wed, 17 Mar 2021 09:06:28 +0100 (CET) Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 3CBDE2C0B11A2; Wed, 17 Mar 2021 09:06:28 +0100 (CET) Date: Wed, 17 Mar 2021 09:06:28 +0100 From: Peter Zijlstra To: changhuaixin Cc: 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 Subject: Re: [PATCH v4 1/4] sched/fair: Introduce primitives for CFS bandwidth burst Message-ID: References: <20210316044931.39733-1-changhuaixin@linux.alibaba.com> <20210316044931.39733-2-changhuaixin@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Mar 17, 2021 at 03:16:18PM +0800, changhuaixin wrote: > > 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. It's not fairness, bandwidth control is about isolation, and burst introduces interference. > In this way, cfs_b->buffer can be removed while cfs_b->max_overrun is > still needed maybe. So what is the typical avg,stdev,max and mode for the workloads where you find you need this? I would really like to put a limit on the burst. IMO a workload that has a burst many times longer than the quota is plain broken.