From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932282AbbGJN2i (ORCPT ); Fri, 10 Jul 2015 09:28:38 -0400 Received: from foss.arm.com ([217.140.101.70]:50978 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932069AbbGJN23 (ORCPT ); Fri, 10 Jul 2015 09:28:29 -0400 Date: Fri, 10 Jul 2015 14:31:10 +0100 From: Morten Rasmussen To: byungchul.park@lge.com Cc: mingo@kernel.org, peterz@infradead.org, linux-kernel@vger.kernel.org, pjt@google.com Subject: Re: [PATCH v2] sched: let __sched_period() use rq's nr_running Message-ID: <20150710133107.GC8668@e105550-lin.cambridge.arm.com> References: <1436515890-10792-1-git-send-email-byungchul.park@lge.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1436515890-10792-1-git-send-email-byungchul.park@lge.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jul 10, 2015 at 05:11:30PM +0900, byungchul.park@lge.com wrote: > From: Byungchul Park > > __sched_period() returns a period which a rq can have. the period has to be > stretched by the number of task *the rq has*, when nr_running > nr_latency. > otherwise, task slice can be very smaller than sysctl_sched_min_granularity > depending on the position of tg hierarchy when CONFIG_FAIR_GROUP_SCHED. > > Signed-off-by: Byungchul Park > --- > 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 09456fc..8ae7aeb 100644 > --- a/kernel/sched/fair.c > +++ b/kernel/sched/fair.c > @@ -635,7 +635,7 @@ static u64 __sched_period(unsigned long nr_running) > */ > static u64 sched_slice(struct cfs_rq *cfs_rq, struct sched_entity *se) > { > - u64 slice = __sched_period(cfs_rq->nr_running + !se->on_rq); > + u64 slice = __sched_period(rq_of(cfs_rq)->nr_running + !se->on_rq); This would stretch the period to fit rq->cfs.h_nr_running (which is equal to rq.nr_running), but I still think that the slice may be smaller than sched_min_granularity for low priority tasks since the slice is scaled by priority. Also, I'm not sure if we want to enforce sched_slice >= sched_min_granularity, it would mean that tasks inside task groups can stretch the overall period and increase latency for non-grouped tasks.