Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755898Ab1BWCD1 (ORCPT ); Tue, 22 Feb 2011 21:03:27 -0500 Received: from fgwmail6.fujitsu.co.jp ([192.51.44.36]:51103 "EHLO fgwmail6.fujitsu.co.jp" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751634Ab1BWCD0 (ORCPT ); Tue, 22 Feb 2011 21:03:26 -0500 X-SecurityPolicyCheck-FJ: OK by FujitsuOutboundMailChecker v1.3.1 Message-ID: <4D646AC0.7030809@jp.fujitsu.com> Date: Wed, 23 Feb 2011 11:02:40 +0900 From: Hidetoshi Seto User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; ja; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Paul Turner CC: linux-kernel@vger.kernel.org, Bharata B Rao , Dhaval Giani , Balbir Singh , Vaidyanathan Srinivasan , Gautham R Shenoy , Srivatsa Vaddagiri , Kamalesh Babulal , Ingo Molnar , Peter Zijlstra , Pavel Emelyanov , Herbert Poetzl , Avi Kivity , Chris Friesen Subject: Re: [CFS Bandwidth Control v4 6/7] sched: hierarchical task accounting for SCHED_OTHER References: <20110216031831.571628191@google.com> <20110216031841.352204682@google.com> In-Reply-To: <20110216031841.352204682@google.com> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1958 Lines: 73 (2011/02/16 12:18), Paul Turner wrote: > @@ -1428,6 +1464,7 @@ enqueue_task_fair(struct rq *rq, struct > update_cfs_shares(cfs_rq); > } > > + account_hier_tasks(&p->se, 1); > hrtick_update(rq); > } > > @@ -1461,6 +1498,7 @@ static void dequeue_task_fair(struct rq > update_cfs_shares(cfs_rq); > } > > + account_hier_tasks(&p->se, -1); > hrtick_update(rq); > } > Why hrtick_update() is need to be delayed after modifying nr_running? You should not impact current hrtick logic without once mentioning. > Index: tip/kernel/sched_rt.c > =================================================================== > --- tip.orig/kernel/sched_rt.c > +++ tip/kernel/sched_rt.c > @@ -906,6 +906,8 @@ enqueue_task_rt(struct rq *rq, struct ta > > if (!task_current(rq, p) && p->rt.nr_cpus_allowed > 1) > enqueue_pushable_task(rq, p); > + > + inc_nr_running(rq); > } > > static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int flags) > @@ -916,6 +918,8 @@ static void dequeue_task_rt(struct rq *r > dequeue_rt_entity(rt_se); > > dequeue_pushable_task(rq, p); > + > + dec_nr_running(rq); > } > > /* I think similar change for sched_stoptask.c is required. In fact I could not boot tip/master with this v4 patchset. It reports rcu stall warns without applying following tweak: --- a/kernel/sched_stoptask.c +++ b/kernel/sched_stoptask.c @@ -35,11 +35,13 @@ static struct task_struct *pick_next_task_stop(struct rq *rq static void enqueue_task_stop(struct rq *rq, struct task_struct *p, int flags) { + inc_nr_running(rq); } static void dequeue_task_stop(struct rq *rq, struct task_struct *p, int flags) { + dec_nr_running(rq); } Thanks, H.Seto -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/