linux-kernel - Re: [PATCH v2 6/6] sched/rt: Remove unnecessary assignment in inc/dec_rt

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20200224134725.lnccpprgrx5rj4di@e107158-lin.cambridge.arm.com>
Date:   Mon, 24 Feb 2020 13:47:25 +0000
From:   Qais Yousef <qais.yousef@....com>
To:     Dietmar Eggemann <dietmar.eggemann@....com>
Cc:     Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        Steven Rostedt <rostedt@...dmis.org>,
        Pavan Kondeti <pkondeti@...eaurora.org>,
        Juri Lelli <juri.lelli@...hat.com>,
        Vincent Guittot <vincent.guittot@...aro.org>,
        Ben Segall <bsegall@...gle.com>, Mel Gorman <mgorman@...e.de>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 6/6] sched/rt: Remove unnecessary assignment in
 inc/dec_rt_migration

On 02/24/20 13:03, Dietmar Eggemann wrote:
> On 24.02.20 12:31, Qais Yousef wrote:
> > On 02/24/20 00:16, Dietmar Eggemann wrote:
> >> On 23.02.20 19:40, Qais Yousef wrote:
> 
> [...]
> 
> >>> -	rt_rq = &rq_of_rt_rq(rt_rq)->rt;
> >>
> >> IMHO, this is here to get the root rt_rq from any rt_rq (task_groups).
> >> Looks like that e.g rt_nr_total is only maintained on root rt_rq's.
> >>
> >> Similar to CFS' &rq_of(cfs_rq)->cfs (cfs_rq_util_change()) to get root
> >> cfs_rq.
> >>
> >> Not sure where CONFIG_RT_GROUP_SCHED=y is used but it's part of the rt
> >> class implementation.
> > 
> > Ah I see. That was obvious.. How about the below comment?
> > 
> > This code is executed only if rt_entity_is_task(), I don't think this grantees
> > that the rt_rq isn't for a group?
> 
> No, an rt task can run in this taskgroup (e.g. "/tg/tg1"), i.e. in
> tg1->rt_rq[cpu].
> 
> The taskgroup skeleton rt_se of e.g. "/tg/tg1/tg11" would also run in
> tg1->rt_rq[cpu] but for those rt_se's we bail out of [inc/dec]_rt_migration.
> 
> > 
> > I need to go and unravel the layers maybe.
> > 
> > Thanks!
> > 
> > --
> > Qais Yousef
> > 
> > -->8--
> > 
> > diff --git a/kernel/sched/rt.c b/kernel/sched/rt.c
> > index b35e49cdafcc..f929867215c4 100644
> > --- a/kernel/sched/rt.c
> > +++ b/kernel/sched/rt.c
> > @@ -343,6 +343,8 @@ static void inc_rt_migration(struct sched_rt_entity *rt_se, struct rt_rq *rt_rq)
> >                 return;
> > 
> >         p = rt_task_of(rt_se);
> > +
> > +       /* get the root rt_rq if this is the rt_rq of a group */
> 
> Not sure if a comment like this will help since:
> 
> (a) the definition of rq_of_rt_rq() for the !CONFIG_RT_GROUP_SCHED case
> 
> (b) rt_rq might already be the root rt_rq in case the task runs in "/"

I thought the comment explains that.

FWIW I don't think someone looking at the code need to look at rq_of_rt_rq() to
get the dependency, but if the above doesn't help I have no better suggestion.
So I'll drop it.

Thanks

--
Qais Yousef