From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752025AbdLFMgf (ORCPT ); Wed, 6 Dec 2017 07:36:35 -0500 Received: from mail-it0-f47.google.com ([209.85.214.47]:39400 "EHLO mail-it0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752319AbdLFMgW (ORCPT ); Wed, 6 Dec 2017 07:36:22 -0500 X-Google-Smtp-Source: AGs4zMZdjJ2EB6Tli4pdbEqhuBltzL6PdZOw2AGx9mUjX1tqG1lRRN94p2wTZATRhUdPwkSLhtIr3xxDa7tuUVyDI7Y= MIME-Version: 1.0 In-Reply-To: <20171206113821.GO31247@e110439-lin> References: <20171130114723.29210-1-patrick.bellasi@arm.com> <20171130114723.29210-5-patrick.bellasi@arm.com> <20171206113821.GO31247@e110439-lin> From: Vincent Guittot Date: Wed, 6 Dec 2017 13:36:00 +0100 Message-ID: Subject: Re: [PATCH v3 4/6] sched/rt: fast switch to maximum frequency when RT tasks are scheduled To: Patrick Bellasi Cc: linux-kernel , "linux-pm@vger.kernel.org" , Ingo Molnar , Peter Zijlstra , "Rafael J . Wysocki" , Viresh Kumar , Dietmar Eggemann , Morten Rasmussen , Juri Lelli , Todd Kjos , Joel Fernandes Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6 December 2017 at 12:38, Patrick Bellasi wrote: > Hi Vincent, > > On 06-Dec 10:39, Vincent Guittot wrote: >> Hi Patrick, >> >> On 30 November 2017 at 12:47, Patrick Bellasi wrote: > > [...] > >> > static void dequeue_task_rt(struct rq *rq, struct task_struct *p, int flags) >> > @@ -1564,6 +1564,9 @@ pick_next_task_rt(struct rq *rq, struct task_struct *prev, struct rq_flags *rf) >> > >> > p = _pick_next_task_rt(rq); >> > >> > + /* Kick cpufreq (see the comment in kernel/sched/sched.h). */ >> >> p is null when there is no rt task to pick. >> You should test this condition before calling cpufreq_update_util > > Mmm... for what I see, from the above function's implementation, > _pick_next_task_rt() is always returning a valid pointer to an RT > task. > > The above call does a: > > p->se.exec_start = rq_clock_task(rq); > > right before returning, and there is also a BUG_ON(!rt_se) in the > previous RT tasks scanning loop. > > Am I missing something? No you're right the return Null is done earlier if there is no task > >> > + cpufreq_update_util(rq, SCHED_CPUFREQ_RT); >> > + >> > /* The running task is never eligible for pushing */ >> > dequeue_pushable_task(rq, p); > > [...] > >> > @@ -2317,6 +2323,9 @@ static void set_curr_task_rt(struct rq *rq) >> > >> > p->se.exec_start = rq_clock_task(rq); >> > >> > + /* Kick cpufreq (see the comment in kernel/sched/sched.h). */ >> > + cpufreq_update_util(rq, SCHED_CPUFREQ_RT); >> >> Is this change linked to the "- when a task is set to be RT" in the >> commit message ? >> >> I can't see a situation where this is call without the previous one. >> AFAICT, enqueue_task_rt will be called before each call to this >> function > > Yeah, you right, in core.c the pattern seems to always be: > > if (queued) > enqueue_task() > if (running) > set_curr_task() > > I'll remove this chunk from the next version. > >> >> > + >> > /* The running task is never eligible for pushing */ >> > dequeue_pushable_task(rq, p); >> > } > > Thanks for the review! > > -- > #include > > Patrick Bellasi