Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1759515Ab1CDMLz (ORCPT ); Fri, 4 Mar 2011 07:11:55 -0500 Received: from e28smtp04.in.ibm.com ([122.248.162.4]:41184 "EHLO e28smtp04.in.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752116Ab1CDMLx (ORCPT ); Fri, 4 Mar 2011 07:11:53 -0500 Date: Fri, 4 Mar 2011 17:41:46 +0530 From: Balbir Singh To: Yong Zhang Cc: "linux-kernel@vger.kernel.org" , Ingo Molnar , Peter Zijlstra , Srivatsa Vaddagiri , Bharata B Rao Subject: Re: [BUGFIX][PATCH] Fix sched rt group scheduling when hierachy is enabled Message-ID: <20110304121146.GG2868@balbir.in.ibm.com> Reply-To: balbir@linux.vnet.ibm.com References: <20110303113435.GA2868@balbir.in.ibm.com> <20110303140551.GA20677@zhy> <20110304072517.GC2868@balbir.in.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2141 Lines: 67 * Yong Zhang [2011-03-04 17:30:58]: > On Fri, Mar 4, 2011 at 4:59 PM, Balbir Singh wrote: > >>>> ?deactivate_task(b); /* A.throttled == 1 && A.rt_nr_running == 0 */ > >>>> ? ?do_sched_rt_period_timer(); /* A.run_time == 0 && A.throttled == 0*/ > >>> > >>> Note at some point rt_time becomes 0 and if enqueue is not set, the > >> > >> If the group should be add back, it will be at the first > >> do_sched_rt_period_timer() which decreases run_time; > >> > > > > As long as idle is 0, the period will continue to run, if it has > > rt_nr_running or rt_time, the timer will run. > > Yep. > Should be the first do_sched_rt_period_timer() which meets > rt_rq->rt_time < runtime :) > > > > >>> next do_sched_rt_period_timer() is a NOP and does not enqueue back the > >>> group > >> > >> Otherwise it will be added back when a task is attching to it. > >> > >> I still can't see how a unthrottled group which has task attched stay > >> unqueued. > > > > The other way of looking at the first change is > > > > Can we have rt_time as 0, rt_nr_running >=1, rt_throttled !=0 and > > still not have the rt_rq enqueued? > > Yeah, the same question. How could we reach that? > I based the changes on what I saw during my debugging/test. I explained it earlier, Everyone is dequeued 1. child runs first, finds parent throttled, so it does not queue anything on parent group. child is unthrottled and rt_time now becomes 0, parent's rt_nr_running is not incremented. 2. Parent timer runs, it is unthrottled, its group->rt_nr_running is 0 hence enqueue is not called > IMHO, rt_time == 0 and rt_throttled !=0 can't coexist. > > > > > If this is not the case, we don't lose much, a quick check for > > rt_nr_running and on_rt_q > > I don't get what you mean here. > I was talking of the overhead of the check I added. -- Three Cheers, Balbir -- 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/