Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1434450 > unrolled thread

Re: [PATCH 3/4] sched/fair: Add REBALANCE_AFFINITY rebalancing code

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH 3/4] sched/fair: Add REBALANCE_AFFINITY rebalancing code Peter Zijlstra <peterz@infradead.org> - 2016-06-30 13:00 +0200
    Re: [PATCH 3/4] sched/fair: Add REBALANCE_AFFINITY rebalancing code Jiri Olsa <jolsa@redhat.com> - 2016-07-01 09:40 +0200
      Re: [PATCH 3/4] sched/fair: Add REBALANCE_AFFINITY rebalancing code Peter Zijlstra <peterz@infradead.org> - 2016-07-01 10:30 +0200
        Re: [PATCH 3/4] sched/fair: Add REBALANCE_AFFINITY rebalancing code Peter Zijlstra <peterz@infradead.org> - 2016-07-01 17:00 +0200

#1434450 — Re: [PATCH 3/4] sched/fair: Add REBALANCE_AFFINITY rebalancing code

On Mon, Jun 20, 2016 at 02:15:13PM +0200, Jiri Olsa wrote:
> Sched domains are defined at the start and can't be changed
> during runtime.

Not entirely true; you can change them using cpusets, although there are
strict constraints on how and you can only make the 'problem' worse.

> If user defines workload affinity settings
> unevenly with sched domains, he could get unbalanced state
> within his affinity group, like:
> 
> Say we have following sched domains:
>   domain 0: (pairs)

s/pairs/smt siblings/

>   domain 1: 0-5,12-17 (group1)  6-11,18-23 (group2)

this would typically be cache groups

>   domain 2: 0-23 level NUMA
> 
> User runs workload with affinity setup that takes
> one CPU from group1 (0) and the rest from group 2:
>     0,6,7,8,9,10,11,18,19,20,21,22

But who would do something like that?

I'm really missing a problem statement here. Who cares and why?

sched_setaffinity() is an interface that says I know what I'm doing, and
you seem to be solving a problem resulting from not actually knowing wth
you're doing.

I'm not saying we shouldn't look into it, but I really want more
justification for this.

> User will see idle CPUs within his affinity group,
> because load balancer will balance tasks based on load
> within group1 and group2, thus placing eqaul load
> of tasks on CPU 0 and on the rest of CPUs.

So afaict this thing only cares about idleness, and we should be able to
fix that differently. The real problem is maintaining fairness in the
overloaded case under such silly constraints.

So why do you only care about this specific issue.

[toc] | [next] | [standalone]

#1435084

On Thu, Jun 30, 2016 at 12:58:05PM +0200, Peter Zijlstra wrote:
> On Mon, Jun 20, 2016 at 02:15:13PM +0200, Jiri Olsa wrote:
> > Sched domains are defined at the start and can't be changed
> > during runtime.
> 
> Not entirely true; you can change them using cpusets, although there are
> strict constraints on how and you can only make the 'problem' worse.
> 
> > If user defines workload affinity settings
> > unevenly with sched domains, he could get unbalanced state
> > within his affinity group, like:
> > 
> > Say we have following sched domains:
> >   domain 0: (pairs)
> 
> s/pairs/smt siblings/
> 
> >   domain 1: 0-5,12-17 (group1)  6-11,18-23 (group2)
> 
> this would typically be cache groups
> 
> >   domain 2: 0-23 level NUMA
> > 
> > User runs workload with affinity setup that takes
> > one CPU from group1 (0) and the rest from group 2:
> >     0,6,7,8,9,10,11,18,19,20,21,22
> 
> But who would do something like that?
> 
> I'm really missing a problem statement here. Who cares and why?
> 
> sched_setaffinity() is an interface that says I know what I'm doing, and
> you seem to be solving a problem resulting from not actually knowing wth
> you're doing.
> 
> I'm not saying we shouldn't look into it, but I really want more
> justification for this.
> 
> > User will see idle CPUs within his affinity group,
> > because load balancer will balance tasks based on load
> > within group1 and group2, thus placing eqaul load
> > of tasks on CPU 0 and on the rest of CPUs.
> 
> So afaict this thing only cares about idleness, and we should be able to
> fix that differently. The real problem is maintaining fairness in the
> overloaded case under such silly constraints.
> 
> So why do you only care about this specific issue.

well this is issue our partner met in the setup,
and I'm not sure what was their motivation for that,
perhaps James could clarify in here..

I tried to make the 'scratch that itch' solution as
mentioned in earlier discussion.

So IIUIC what you say is that it needs to be more generic
solution..?  I'll continue staring at it then ;-)

thanks,
jirka

[toc] | [prev] | [next] | [standalone]

#1435145

On Fri, Jul 01, 2016 at 09:35:46AM +0200, Jiri Olsa wrote:
> well this is issue our partner met in the setup,
> and I'm not sure what was their motivation for that,
> perhaps James could clarify in here..
> 
> I tried to make the 'scratch that itch' solution as
> mentioned in earlier discussion.
> 
> So IIUIC what you say is that it needs to be more generic
> solution..?  I'll continue staring at it then ;-)

I just want to know what problem we're trying to solve..

Because it appears this is running 1 task each on a 'weird' subset of
cpus and things going badly. If this really is the case, then teaching
active balance to only move tasks to idle cpus or something should also
cure things.

Also, I'm curious why people set such weird masks.

[toc] | [prev] | [next] | [standalone]

#1435396

On Fri, Jul 01, 2016 at 09:15:55AM -0500, James Hartsock wrote:
> On Fri, Jul 1, 2016 at 3:24 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> 
> > On Fri, Jul 01, 2016 at 09:35:46AM +0200, Jiri Olsa wrote:
> > > well this is issue our partner met in the setup,
> > > and I'm not sure what was their motivation for that,
> > > perhaps James could clarify in here..
> > >
> > > I tried to make the 'scratch that itch' solution as
> > > mentioned in earlier discussion.
> > >
> > > So IIUIC what you say is that it needs to be more generic
> > > solution..?  I'll continue staring at it then ;-)
> >
> > I just want to know what problem we're trying to solve..
> >
> > Because it appears this is running 1 task each on a 'weird' subset of
> > cpus and things going badly. If this really is the case, then teaching
> > active balance to only move tasks to idle cpus or something should also
> > cure things.
> >
> > Also, I'm curious why people set such weird masks.
> >
> 
> ​I think the original issue was reported/seen when using a straight range
> of CPUs, but in that range they crossed numa nodes.  Then in the no knowing
> what was triggering the issue and trying to reproduce the issue we started
> getting some crazy masks.
> 
> The work-around customer has been using is to use SCHED_RR as it doesn't
> have this balance across NUMA issue​.  But it is also the fact that
> SCHED_RR doesn't have this issue that makes it "seem" like a defect in
> SCHED_OTHER.  I have shared that this is triggered by the across numa node
> taskset with customer so they are aware of that.  But if this is something
> that is seen as a limitation of SCHED_OTHER and not reasonable to be
> addressed upstream I think maybe it as least something we should get
> documented.

But what exact usecase? A single task per cpu, or something else?

Note that RR has different constraints than OTHER, but in both cases
having skewed masks across a topology divide is unlikely to be good for
performance.

Esp. in the extreme case reported here, where one task is on an entirely
different node than the rest of them, that task will cause cacheline
transfers between the nodes slowing down itself as well as all the other
tasks that have to pull it back in.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web