On Fri, Nov 20, 2020 at 11:58:54AM -0500, Joel Fernandes wrote:
> On Fri, Nov 20, 2020 at 10:56:09AM +1100, Singh, Balbir wrote:
> [..]
> > > +#ifdef CONFIG_SMP
> > > +static struct task_struct *pick_task_fair(struct rq *rq)
> > > +{
> > > + struct cfs_rq *cfs_rq = &rq->cfs;
> > > + struct sched_entity *se;
> > > +
> > > + if (!cfs_rq->nr_running)
> > > + return NULL;
> > > +
> > > + do {
> > > + struct sched_entity *curr = cfs_rq->curr;
> > > +
> > > + se = pick_next_entity(cfs_rq, NULL);
> > > +
> > > + if (curr) {
> > > + if (se && curr->on_rq)
> > > + update_curr(cfs_rq);
> > > +
> > > + if (!se || entity_before(curr, se))
> > > + se = curr;
> > > + }
> >
> > Do we want to optimize this a bit
> >
> > if (curr) {
> > if (!se || entity_before(curr, se))
> > se = curr;
> >
> > if ((se != curr) && curr->on_rq)
> > update_curr(cfs_rq);
> >
> > }
>
> Do you see a difference in codegen? What's the optimization?
>
> Also in later patches this code changes, so it should not matter:
> See: 3e0838fa3c51 ("sched/fair: Fix pick_task_fair crashes due to empty
> rbtree")
>
I did see the next patch, but the idea is that we don't need to
update_curr() if the picked sched entity is the same as current (se ==
curr). What are the side-effects of not updating curr when se == curr?
Balbir
