From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on archive.lwn.net X-Spam-Level: X-Spam-Status: No, score=-13.6 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, RCVD_IN_DNSWL_HI,SPF_HELO_NONE,SPF_NONE,T_DKIMWL_WL_MED, USER_IN_DEF_DKIM_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by archive.lwn.net (Postfix) with ESMTP id BA1A37D919 for ; Wed, 29 May 2019 19:50:26 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726038AbfE2Tu0 (ORCPT ); Wed, 29 May 2019 15:50:26 -0400 Received: from mail-pl1-f196.google.com ([209.85.214.196]:37347 "EHLO mail-pl1-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726099AbfE2Tu0 (ORCPT ); Wed, 29 May 2019 15:50:26 -0400 Received: by mail-pl1-f196.google.com with SMTP id e7so1019209pln.4 for ; Wed, 29 May 2019 12:50:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=z596bta4rnvntAQDgf+fFcauM3ob59dKjWY1OdsYMKo=; b=pE1DG7jxvSSAUIngdKKy8SGdjXwNZF0gKUEfIO7uIOz19XZQLPVNGTFcfJvyXyO3W9 FQwJJn15+yK86NLne5wN9s8kpifZsp+U7+HedfghIBYeUQBULzTgSZqoucRCcEvJr8sC RYF07nkoPv0kjyLAW8qfe3qOWb1gCyKuTytRud3LD2WRPBzI+yw5iH4ELti4VEqkfqt7 9zclBKHZtmYjOsWw0NB0DSHFDCOaetAq68wYIlk36kwfooWpH6SbbQYPdxOW2Mo06ugy t2KLfNWlEZid2pIRCCKt53pYGHq++hzN4JwX+kbVcDpMc0o0LKhxXZTV5V7JQefcSiNs RoaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=z596bta4rnvntAQDgf+fFcauM3ob59dKjWY1OdsYMKo=; b=Y5YIX+cXHLrY8HAwKwgLddKbeg/8hS9t/Z0gs/srgOXQikgxKoZUkzANyjWpnO5xEy snVn/lE4/U2MZkFU7v7iKgTFfxU3PkenYlyvubfWcING2NiNGa4Y1HuZ76hCdY0lJJrx 3fyh0zEWN2Amo5rjYwhGId3ygG8sIF64dFcUYgZ4PwqF+wkew7QLIJkb/Fc7WobIoY0P DkTFW4QdrL5uzpAlY4J4CZLe3DbzoYrROM5u3X1gDc7Tb3+Yr0PyEc4nTg0DejUlztzO 3HZne6loLfuC2e3VWaSA04WQmR3TPIf2pruKsrHS1XgTUWA8GBRDsa/MA3M7L4zXcttr Fc8w== X-Gm-Message-State: APjAAAVyegxElglKM/7loCMucPq4dKq0NRzoyCe7854ZcbcfdrSUCl9X XA6kScBpqiHUT+GB98bNXhDN9EMNN+cB7Q== X-Google-Smtp-Source: APXvYqzshZY21kMgFt9d+UvNrC6OFcaddc20fC0x4wy/KNegBKhcXaTRMqjJX9jyuiwlFYIxPwfPvA== X-Received: by 2002:a17:902:8d96:: with SMTP id v22mr68846995plo.282.1559159424386; Wed, 29 May 2019 12:50:24 -0700 (PDT) Received: from bsegall-linux.svl.corp.google.com.localhost ([2620:15c:2cd:202:39d7:98b3:2536:e93f]) by smtp.gmail.com with ESMTPSA id d13sm499407pfh.113.2019.05.29.12.50.22 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 29 May 2019 12:50:23 -0700 (PDT) From: bsegall@google.com To: Dave Chiluk Cc: Phil Auld , Peter Oskolkov , Peter Zijlstra , Ingo Molnar , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, Brendan Gregg , Kyle Anderson , Gabriel Munos , John Hammond , Cong Wang , Jonathan Corbet , linux-doc@vger.kernel.org Subject: Re: [PATCH v3 1/1] sched/fair: Fix low cpu usage with high throttling by removing expiration of cpu-local slices References: <1558121424-2914-1-git-send-email-chiluk+linux@indeed.com> <1559156926-31336-1-git-send-email-chiluk+linux@indeed.com> <1559156926-31336-2-git-send-email-chiluk+linux@indeed.com> Date: Wed, 29 May 2019 12:50:22 -0700 In-Reply-To: <1559156926-31336-2-git-send-email-chiluk+linux@indeed.com> (Dave Chiluk's message of "Wed, 29 May 2019 14:08:46 -0500") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain Sender: linux-doc-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-doc@vger.kernel.org Dave Chiluk writes: > It has been observed, that highly-threaded, non-cpu-bound applications > running under cpu.cfs_quota_us constraints can hit a high percentage of > periods throttled while simultaneously not consuming the allocated > amount of quota. This use case is typical of user-interactive non-cpu > bound applications, such as those running in kubernetes or mesos when > run on multiple cpu cores. > > This has been root caused to threads being allocated per cpu bandwidth > slices, and then not fully using that slice within the period. At which > point the slice and quota expires. This expiration of unused slice > results in applications not being able to utilize the quota for which > they are allocated. > So most of the bandwidth is supposed to be returned, leaving only 1ms. I'm setting up to try your test now, but there was a bug with the unthrottle part of this where it could be continuously pushed into the future. You might try this patch instead, possibly along with lowering min_cfs_rq_runtime (currently not runtime tunable) if you see that cost more than the cost of extra locking to acquire runtime. From: Ben Segall Date: Tue, 28 May 2019 12:30:25 -0700 Subject: [PATCH] sched/fair: don't push cfs_bandwith slack timers forward When a cfs_rq sleeps and returns its quota, we delay for 5ms before waking any throttled cfs_rqs to coalesce with other cfs_rqs going to sleep, as this has has to be done outside of the rq lock we hold. The current code waits for 5ms without any sleeps, instead of waiting for 5ms from the first sleep, which can delay the unthrottle more than we want. Switch this around. Change-Id: Ife536bb54af633863de486ba6ec0d20e55ada8c9 Signed-off-by: Ben Segall --- kernel/sched/fair.c | 7 +++++++ kernel/sched/sched.h | 1 + 2 files changed, 8 insertions(+) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 8213ff6e365d..2ead252cfa32 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -4729,6 +4729,11 @@ static void start_cfs_slack_bandwidth(struct cfs_bandwidth *cfs_b) if (runtime_refresh_within(cfs_b, min_left)) return; + /* don't push forwards an existing deferred unthrottle */ + if (cfs_b->slack_started) + return; + cfs_b->slack_started = true; + hrtimer_start(&cfs_b->slack_timer, ns_to_ktime(cfs_bandwidth_slack_period), HRTIMER_MODE_REL); @@ -4782,6 +4787,7 @@ static void do_sched_cfs_slack_timer(struct cfs_bandwidth *cfs_b) /* confirm we're still not at a refresh boundary */ raw_spin_lock_irqsave(&cfs_b->lock, flags); + cfs_b->slack_started = false; if (cfs_b->distribute_running) { raw_spin_unlock_irqrestore(&cfs_b->lock, flags); return; @@ -4920,6 +4926,7 @@ void init_cfs_bandwidth(struct cfs_bandwidth *cfs_b) hrtimer_init(&cfs_b->slack_timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL); cfs_b->slack_timer.function = sched_cfs_slack_timer; cfs_b->distribute_running = 0; + cfs_b->slack_started = false; } static void init_cfs_rq_runtime(struct cfs_rq *cfs_rq) diff --git a/kernel/sched/sched.h b/kernel/sched/sched.h index efa686eeff26..60219acda94b 100644 --- a/kernel/sched/sched.h +++ b/kernel/sched/sched.h @@ -356,6 +356,7 @@ struct cfs_bandwidth { u64 throttled_time; bool distribute_running; + bool slack_started; #endif }; -- 2.22.0.rc1.257.g3120a18244-goog