Received: by 2002:ac0:a5b6:0:0:0:0:0 with SMTP id m51-v6csp3688497imm; Mon, 18 Jun 2018 02:19:20 -0700 (PDT) X-Google-Smtp-Source: ADUXVKLdp32EsWbiOOyUsKZgkg6GdtLyk8OjvH5GCwHQV4YRLhuIPfJMzve+L1wk859vcSd53po8 X-Received: by 2002:a65:528c:: with SMTP id y12-v6mr10317394pgp.157.1529313560204; Mon, 18 Jun 2018 02:19:20 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1529313559; cv=none; d=google.com; s=arc-20160816; b=KxxsiWkCsrsfiy15eXkQt9kG3m9Tw4jL91Y5poZiI2E/Fve3Wnultg+w8NrlWUFDFf rbAAGgVlz2fik8a02Rix9/ybydfUjJxVxfy8VZpL5av08QhmoKzL6evi/dpS5r2q14ks b/YWG7aqJlKs21JRKsiqKiizUk22owEM81WumvAnx4+3+hEAlCktR2YvkMN7JxZqGz3E +Slc7vZWwR4dcLd4mDojtvmEYY4RMvkeOvuUMPelZYls8ABakKqqJr9ZCeCHaClQ1lnG 1+mfMWt8Jqt3lHnMqUikanZoF1tR49w6Jhe5ecoz2U5FPk5Pw5MQq5mI29EIGzJrDhm3 t2AQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:message-id:date:subject:cc:to:from :arc-authentication-results; bh=C8wKk2gkremo7gzhiXUv4xKrgc4VUlZLdawptoAQ26I=; b=N1X1GeC5cA/E6nk1JMIx58EdIXLlGZsCacCKbomBLMB9tUE3nGS9il6kWukct/TdpX 5ZZaH9Z1trjSFdTbQZPaHxYTbMcTLaxhbyFHcEIjwQWmBmtONKRPmfPBGTPaV0bI7vzA wG9Ite6BNSAnScKQ0jrLGQhPofNb81zNLMtBba8ODjXg46nV/BF1kRcS94/Sv/9+9a0q eykKaiLrGHOBcCy6dJ9NqlI25KhT1kMGywxYFarHxt/me1QuPCxBQVm/a2RFYi14Mnc3 rmqsn/PuGBYKzX+wtY6rzTMH+jN+XTNEj3p04Oya560pu43vThGE9M7tsWE4GfiBFrmX W/rQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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. [209.132.180.67]) by mx.google.com with ESMTP id w2-v6si14909963ply.395.2018.06.18.02.19.05; Mon, 18 Jun 2018 02:19:19 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 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 S966866AbeFRJRU (ORCPT + 99 others); Mon, 18 Jun 2018 05:17:20 -0400 Received: from out30-130.freemail.mail.aliyun.com ([115.124.30.130]:48949 "EHLO out30-130.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S966608AbeFRJRT (ORCPT ); Mon, 18 Jun 2018 05:17:19 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R211e4;CH=green;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01f04455;MF=xlpang@linux.alibaba.com;NM=1;PH=DS;RN=4;SR=0;TI=SMTPD_---0T2wsk0g_1529313417; Received: from localhost(mailfrom:xlpang@linux.alibaba.com fp:SMTPD_---0T2wsk0g_1529313417) by smtp.aliyun-inc.com(127.0.0.1); Mon, 18 Jun 2018 17:17:05 +0800 From: Xunlei Pang To: Peter Zijlstra , Ingo Molnar , Ben Segall Cc: linux-kernel@vger.kernel.org Subject: [PATCH 2/2] sched/fair: Advance global expiration when period timer is restarted Date: Mon, 18 Jun 2018 17:16:57 +0800 Message-Id: <20180618091657.21939-1-xlpang@linux.alibaba.com> X-Mailer: git-send-email 2.14.1.40.g8e62ba1 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org I noticed the group frequently got throttled even it consumed low cpu usage, this caused some jitters on the response time to some of our business containers enabling cpu quota. It's very easy to reproduce: mkdir /sys/fs/cgroup/cpu/test cd /sys/fs/cgroup/cpu/test echo 100000 > cpu.cfs_quota_us echo $$ > tasks then repeat: cat cpu.stat |grep nr_throttled // nr_throttled will increase After some analysis, we found that cfs_rq::runtime_remaining will be cleared by expire_cfs_rq_runtime() due to two equal but stale "cfs_{b|q}->runtime_expires" after period timer is re-armed. The global expiration should be advanced accordingly when the bandwidth period timer is restarted. Signed-off-by: Xunlei Pang --- kernel/sched/fair.c | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 9f384264e832..bb006e671609 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -5204,13 +5204,18 @@ static void init_cfs_rq_runtime(struct cfs_rq *cfs_rq) void start_cfs_bandwidth(struct cfs_bandwidth *cfs_b) { + u64 overrun; + lockdep_assert_held(&cfs_b->lock); - if (!cfs_b->period_active) { - cfs_b->period_active = 1; - hrtimer_forward_now(&cfs_b->period_timer, cfs_b->period); - hrtimer_start_expires(&cfs_b->period_timer, HRTIMER_MODE_ABS_PINNED); - } + if (cfs_b->period_active) + return; + + cfs_b->period_active = 1; + overrun = hrtimer_forward_now(&cfs_b->period_timer, cfs_b->period); + cfs_b->runtime_expires += (overrun + 1) * ktime_to_ns(cfs_b->period); + cfs_b->expires_seq++; + hrtimer_start_expires(&cfs_b->period_timer, HRTIMER_MODE_ABS_PINNED); } static void destroy_cfs_bandwidth(struct cfs_bandwidth *cfs_b) -- 2.14.1.40.g8e62ba1