Received: by 2002:a05:6a10:f347:0:0:0:0 with SMTP id d7csp1030489pxu; Wed, 16 Dec 2020 23:47:46 -0800 (PST) X-Google-Smtp-Source: ABdhPJxbFQT5wz6MB0WTNEDU7Of3M1vXD9HzUe8YHqJLCqCW0FYatxQYh2NjL8HetcqysjY8qkaJ X-Received: by 2002:a05:6402:388:: with SMTP id o8mr37011185edv.359.1608191266038; Wed, 16 Dec 2020 23:47:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1608191266; cv=none; d=google.com; s=arc-20160816; b=wmK/tpVI3YoqNEUXz8Isj96lbZQCs7TGDfyYCm5xUNKpkS2CTHDz5ZA98w2U6ZJk7e PTfTtQnweT0Vkpp8tnRfB/eTXBvxGYsE7CEZcW0tRXQxVSpeS02mG0OmYNQO8gP6/2Fn xmu6SxUIZsoMVyzRLQcquRG53O0o9YiHwwbVC80f2D+TNYN29ml/dhl1RvVpCQOa36ng 6uDaVmqNJOvL1aynYx6uLwLs5i5eYb6LoV1PfKz5rE9vhoXWp9aBreZZOuQPMobF9Br0 nFXrrsyMpAcpbXWeanMCuaVLvqmOMu64bTAL4yA0Lv/dw2YqVZJZmGMqhdzgg3h4sHNC USJg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:mime-version :message-id:date:subject:cc:to:from; bh=KAYVeP60VkhhRo/8XC3dNQEN5rYP7gyMNNq4f7h23FU=; b=sQ2TKaVdtS8ra8vDj7+SdUgyP6me83CN9jCDcCmPYuKdylX4bi7KRDWe62Tb6EU2fG M09KlM9XFc0BALkId2cMNYYehy7XRAJrFYJn5nNk2UOmjpqXsQejcoq/dH644xnkJfqp 4lwxh81Ytv6N0CXesFgjlvc/KxElJ2j+l4Rkx1fMp6zk5tjBj6Rj3x6Oqb20IwZBhwIL PjH0rDFrNSjztpzv5gNxRD/sfGAO+tV+GoB8vmFRvMQ6kfqEFS1lZ188rL4mNRl6PJpp d8cHIvdHU9dUogyMu4GLAb2WAekPxIG6ZAnFFMTP/JA2C9hNmJIJWECaoU/yYLTtjzI4 UlrQ== 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 e19si3968054edv.458.2020.12.16.23.47.23; Wed, 16 Dec 2020 23:47:46 -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 S1726547AbgLQHrQ (ORCPT + 99 others); Thu, 17 Dec 2020 02:47:16 -0500 Received: from out30-54.freemail.mail.aliyun.com ([115.124.30.54]:40560 "EHLO out30-54.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726012AbgLQHrP (ORCPT ); Thu, 17 Dec 2020 02:47:15 -0500 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R891e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04357;MF=changhuaixin@linux.alibaba.com;NM=1;PH=DS;RN=15;SR=0;TI=SMTPD_---0UIuSawr_1608191189; Received: from localhost(mailfrom:changhuaixin@linux.alibaba.com fp:SMTPD_---0UIuSawr_1608191189) by smtp.aliyun-inc.com(127.0.0.1); Thu, 17 Dec 2020 15:46:29 +0800 From: Huaixin Chang To: linux-kernel@vger.kernel.org Cc: bsegall@google.com, changhuaixin@linux.alibaba.com, dietmar.eggemann@arm.com, juri.lelli@redhat.com, mgorman@suse.de, mingo@redhat.com, pauld@redhead.com, peterz@infradead.org, pjt@google.com, rostedt@goodmis.org, vincent.guittot@linaro.org, khlebnikov@yandex-team.ru, xiyou.wangcong@gmail.com, shanpeic@linux.alibaba.com Subject: [PATCH 0/4] sched/fair: Burstable CFS bandwidth controller Date: Thu, 17 Dec 2020 15:46:16 +0800 Message-Id: <20201217074620.58338-1-changhuaixin@linux.alibaba.com> X-Mailer: git-send-email 2.14.4.44.g2045bb6 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org The CFS bandwidth controller limits CPU requests of a task group to quota during each period. However, parallel workloads might be bursty so that they get throttled. And they are latency sensitive at the same time so that throttling them is undesired. Scaling up period and quota allows greater burst capacity. But it might cause longer stuck till next refill. We introduce "burst" to allow accumulating unused quota from previous periods, and to be assigned when a task group requests more CPU than quota during a specific period. Thus allowing CPU time requests as long as the average requested CPU time is below quota on the long run. The maximum accumulation is capped by burst and is set 0 by default, thus the traditional behaviour remains. A huge drop of 99th tail latency from more than 500ms to 27ms is seen for real java workloads when using burst. Similar drops are seen when testing with schbench too: echo $$ > /sys/fs/cgroup/cpu/test/cgroup.procs echo 700000 > /sys/fs/cgroup/cpu/test/cpu.cfs_quota_us echo 100000 > /sys/fs/cgroup/cpu/test/cpu.cfs_period_us echo 400000 > /sys/fs/cgroup/cpu/test/cpu.cfs_burst_us # The average CPU usage is around 500%, which is 200ms CPU time # every 40ms. ./schbench -m 1 -t 30 -r 60 -c 10000 -R 500 Without burst: Latency percentiles (usec) 50.0000th: 7 75.0000th: 8 90.0000th: 9 95.0000th: 10 *99.0000th: 933 99.5000th: 981 99.9000th: 3068 min=0, max=20054 rps: 498.31 p95 (usec) 10 p99 (usec) 933 p95/cputime 0.10% p99/cputime 9.33% With burst: Latency percentiles (usec) 50.0000th: 7 75.0000th: 8 90.0000th: 9 95.0000th: 9 *99.0000th: 12 99.5000th: 13 99.9000th: 19 min=0, max=406 rps: 498.36 p95 (usec) 9 p99 (usec) 12 p95/cputime 0.09% p99/cputime 0.12% How much workloads with benefit from burstable CFS bandwidth control depends on how bursty and how latency sensitive they are. Previously, Cong Wang and Konstantin Khlebnikov proposed similar feature: https://lore.kernel.org/lkml/20180522062017.5193-1-xiyou.wangcong@gmail.com/ https://lore.kernel.org/lkml/157476581065.5793.4518979877345136813.stgit@buzz/ This time we present more latency statistics and handle overflow while accumulating. Huaixin Chang (4): sched/fair: Introduce primitives for CFS bandwidth burst sched/fair: Make CFS bandwidth controller burstable sched/fair: Add cfs bandwidth burst statistics sched/fair: Add document for burstable CFS bandwidth control Documentation/scheduler/sched-bwc.rst | 49 +++++++++++-- include/linux/sched/sysctl.h | 2 + kernel/sched/core.c | 126 +++++++++++++++++++++++++++++----- kernel/sched/fair.c | 58 +++++++++++++--- kernel/sched/sched.h | 9 ++- kernel/sysctl.c | 18 +++++ 6 files changed, 232 insertions(+), 30 deletions(-) -- 2.14.4.44.g2045bb6