Messages in this thread | | | Date | Tue, 2 Apr 2019 09:42:35 +0200 | From | Peter Zijlstra <> | Subject | Re: [RFC][PATCH 03/16] sched: Wrap rq::lock access |
| |
On Fri, Mar 29, 2019 at 03:23:14PM -0700, Subhra Mazumdar wrote: > > On 3/29/19 6:35 AM, Julien Desfossez wrote: > > On Fri, Mar 22, 2019 at 8:09 PM Subhra Mazumdar <subhra.mazumdar@oracle.com> > > wrote: > > > Is the core wide lock primarily responsible for the regression? I ran > > > upto patch > > > 12 which also has the core wide lock for tagged cgroups and also calls > > > newidle_balance() from pick_next_task(). I don't see any regression. Of > > > course > > > the core sched version of pick_next_task() may be doing more but > > > comparing with > > > the __pick_next_task() it doesn't look too horrible. > > On further testing and investigation, we also agree that spinlock contention > > is not the major cause for the regression, but we feel that it should be one > > of the major contributing factors to this performance loss. > > > > > I finally did some code bisection and found the following lines are > basically responsible for the regression. Commenting them out I don't see > the regressions. Can you confirm? I am yet to figure if this is needed for > the correctness of core scheduling and if so can we do this better?
It was meant to be an optimization; specifically, when no cookie was set, don't bother to schedule the sibling(s).
> -------->8------------- > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index fe3918c..3b3388a 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -3741,8 +3741,8 @@ pick_next_task(struct rq *rq, struct task_struct > *prev, struct rq_flags *rf) > * If there weren't no cookies; we don't > need > * to bother with the other siblings. > */ > - if (i == cpu && !rq->core->core_cookie) > - goto next_class; > + //if (i == cpu && !rq->core->core_cookie) > + //goto next_class; > > continue; > }
| |