From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752829AbcISSIT (ORCPT ); Mon, 19 Sep 2016 14:08:19 -0400 Received: from smtp.codeaurora.org ([198.145.29.96]:57402 "EHLO smtp.codeaurora.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751085AbcISSIS (ORCPT ); Mon, 19 Sep 2016 14:08:18 -0400 DMARC-Filter: OpenDMARC Filter v1.3.1 smtp.codeaurora.org 8D332611F1 Authentication-Results: pdx-caf-mail.web.codeaurora.org; dmarc=none header.from=codeaurora.org Authentication-Results: pdx-caf-mail.web.codeaurora.org; spf=pass smtp.mailfrom=joonwoop@codeaurora.org Date: Mon, 19 Sep 2016 11:08:16 -0700 From: Joonwoo Park To: Wanpeng Li Cc: Peter Zijlstra , Srivatsa Vaddagiri , Ingo Molnar , "linux-kernel@vger.kernel.org" Subject: Re: [PATCH] sched: Fix SCHED_HRTICK bug leading to late preemption of tasks Message-ID: <20160919180816.joz2mydmgxmtuvdr@codeaurora.org> References: <1474075731-11550-1-git-send-email-joonwoop@codeaurora.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.1-neo (2016-06-11) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sun, Sep 18, 2016 at 07:28:32AM +0800, Wanpeng Li wrote: > 2016-09-17 9:28 GMT+08:00 Joonwoo Park : > > From: Srivatsa Vaddagiri > > > > SCHED_HRTICK feature is useful to preempt SCHED_FAIR tasks on-the-dot > > (just when they would have exceeded their ideal_runtime). It makes use > > of a per-cpu hrtimer resource and hence alarming that hrtimer should > > be based on total SCHED_FAIR tasks a cpu has across its various cfs_rqs, > > rather than being based on number of tasks in a particular cfs_rq (as > > implemented currently). As a result, with current code, its possible for > > a running task (which is the sole task in its cfs_rq) to be preempted > > not be preempted much, right? I don't think so.... By saying 'to be preempted much after its ideal_runtime has elapsed' I wanted to describe the current suboptimal behaviour. Thanks, Joonwoo > > > much after its ideal_runtime has elapsed, resulting in increased latency > > for tasks in other cfs_rq on same cpu. > > > > Fix this by alarming sched hrtimer based on total number of SCHED_FAIR > > tasks a CPU has across its various cfs_rqs. > > > > Cc: Ingo Molnar > > Cc: Peter Zijlstra > > Cc: linux-kernel@vger.kernel.org > > Signed-off-by: Srivatsa Vaddagiri > > Signed-off-by: Joonwoo Park > > --- > > > > joonwoop: Do we also need to update or remove if-statement inside > > hrtick_update()? > > I guess not because hrtick_update() doesn't want to start hrtick when cfs_rq > > has large number of nr_running where slice is longer than sched_latency. > > > > kernel/sched/fair.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c > > index 4088eed..c55c566 100644 > > --- a/kernel/sched/fair.c > > +++ b/kernel/sched/fair.c > > @@ -4458,7 +4458,7 @@ static void hrtick_start_fair(struct rq *rq, struct task_struct *p) > > > > WARN_ON(task_rq(p) != rq); > > > > - if (cfs_rq->nr_running > 1) { > > + if (rq->cfs.h_nr_running > 1) { > > u64 slice = sched_slice(cfs_rq, se); > > u64 ran = se->sum_exec_runtime - se->prev_sum_exec_runtime; > > s64 delta = slice - ran; > > -- > > The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum, > > hosted by The Linux Foundation > >