Received: by 2002:a25:1985:0:0:0:0:0 with SMTP id 127csp3172977ybz; Sun, 19 Apr 2020 19:46:45 -0700 (PDT) X-Google-Smtp-Source: APiQypLK4SM9C6gHhoXOxBAX+rRPJE24qbPw2SWvcsLSjTRdEfG7rPz/JL+xt/jOXO/NzEgA5MoP X-Received: by 2002:a50:aca3:: with SMTP id x32mr12701596edc.368.1587350804814; Sun, 19 Apr 2020 19:46:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1587350804; cv=none; d=google.com; s=arc-20160816; b=bdIfewkAQb7Ws3Y0FQF5rmDigh11QyrHb7PEvaS9Kz8Tb6zJUsMjBsMwrKRFDOg2wX wv8KfmBbl+0i6MUWIoqqAlA/mEIC5iDpZhTtd20pymPJeX0dBn5lNofyhnbapb5c1cYO Dz7UghwnOCojpivSAPPvm78kp/icNId+P7/n1P8gu929y34Qog21CVpBoC8+7DFCmlLB QBfXHJcs9q7aGf4kTUDXvOE1bZkvnoELwH5kj8OMZCNS01V0Aw7DpcbW+a0S+FZHjtw+ 7sMVuq+GrLaF40U+boyp3YkMod2wKHs1QPbomUoxWr41LNV+Z4OpXqZpqTyYT+A+VEkr sJzQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:date:subject:cc:to:from; bh=ztsG64BhbAwCe95rH9x9IcXKztV10ff6iC5er5rKuKE=; b=GZ3MKj8FrnJhwicLb3RX+ChatKzX8u+lNxAe0N1blq5M/k9bcRVExuuqjc7XoP8ca5 FxVg/uU125RY2KQS47WYSoIxKynKTWugRtKofz0VIQrRxHGYq+ZbiHa7xJnF15fMPezl oqeX1Z4HnmeUrvK2Y1hcKa9vs3fggWKX6q8G0dZmA5LhEjvqa8XLbitejdhEpZaX0qKM wmrez/fhCovdevrVsPabHo54zvfPfa+KVK48J+d5Vn1Il2tZanCcRANxBxy8Hf+uPE5+ 31lMtn8KRwVKQNtobE+paHiz2175Z7fleDFyIM0YoW/eXDikisg7WytRMOcKVOFlXTJR up+Q== 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 oz15si10753944ejb.24.2020.04.19.19.46.22; Sun, 19 Apr 2020 19:46:44 -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; 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 S1726115AbgDTCos (ORCPT + 99 others); Sun, 19 Apr 2020 22:44:48 -0400 Received: from out30-43.freemail.mail.aliyun.com ([115.124.30.43]:55671 "EHLO out30-43.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725865AbgDTCor (ORCPT ); Sun, 19 Apr 2020 22:44:47 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R481e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04394;MF=changhuaixin@linux.alibaba.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---0Tw0VEVY_1587350682; Received: from localhost(mailfrom:changhuaixin@linux.alibaba.com fp:SMTPD_---0Tw0VEVY_1587350682) by smtp.aliyun-inc.com(127.0.0.1); Mon, 20 Apr 2020 10:44:45 +0800 From: Huaixin Chang To: linux-kernel@vger.kernel.org Cc: peterz@infradead.org, mingo@redhat.com, bsegall@google.com, chiluk+linux@indeed.com, vincent.guittot@linaro.org, pauld@redhead.com, Huaixin Chang Subject: [PATCH 2/2] sched/fair: Refill bandwidth before scaling Date: Mon, 20 Apr 2020 10:44:21 +0800 Message-Id: <20200420024421.22442-3-changhuaixin@linux.alibaba.com> X-Mailer: git-send-email 2.14.4.44.g2045bb6 In-Reply-To: <20200420024421.22442-1-changhuaixin@linux.alibaba.com> References: <20200420024421.22442-1-changhuaixin@linux.alibaba.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org In order to prevent possible hardlockup of sched_cfs_period_timer() loop, loop count is introduced to denote whether to scale quota and period or not. However, scale is done between forwarding period timer and refilling cfs bandwidth runtime, which means that period timer is forwarded with old "period" while runtime is refilled with scaled "quota". Move do_sched_cfs_period_timer() before scaling to solve this. Fixes: 2e8e19226398 ("sched/fair: Limit sched_cfs_period_timer() loop to avoid hard lockup") Signed-off-by: Huaixin Chang --- kernel/sched/fair.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 02f323b85b6d..9ace1c5c73a5 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -5152,6 +5152,8 @@ static enum hrtimer_restart sched_cfs_period_timer(struct hrtimer *timer) if (!overrun) break; + idle = do_sched_cfs_period_timer(cfs_b, overrun, flags); + if (++count > 3) { u64 new, old = ktime_to_ns(cfs_b->period); @@ -5181,8 +5183,6 @@ static enum hrtimer_restart sched_cfs_period_timer(struct hrtimer *timer) /* reset count so we don't come right back in here */ count = 0; } - - idle = do_sched_cfs_period_timer(cfs_b, overrun, flags); } if (idle) cfs_b->period_active = 0; -- 2.14.4.44.g2045bb6