Re: [PATCH RFC/RFT] sched/fair: Improve the behavior of sync flag

[Mike Galbraith]

On Mon, 2017-08-28 at 09:20 -0700, Joel Fernandes wrote:
> Hi Mike,
> 
> On Sun, Aug 27, 2017 at 11:10 PM, Mike Galbraith <efault@xxxxxx> wrote:
> > On Sun, 2017-08-27 at 22:27 -0700, Joel Fernandes wrote:
> >> Hi Mike,
> >>
> >> On Sun, Aug 27, 2017 at 11:07 AM, Mike Galbraith <efault@xxxxxx> wrote:
> >> > On Sat, 2017-08-26 at 23:39 -0700, Joel Fernandes wrote:
> >> >>
> >> >> Also about real world benchmarks, in Android we have usecases that
> >> >> show that the graphics performance and we have risk of frame drops if
> >> >> we don't use the sync flag so this is a real world need.
> >> >
> >> > That likely has everything to do with cpufreq not realizing that your
> >> > CPUs really are quite busy when scheduling cross core at fairly high
> >> > frequency, and not clocking up properly.
> >> >
> >>
> >> I'm glad you brought this point up. Since Android O, the userspace
> >> processes are much more split across procedure calls due to a feature
> >> called treble (which does this for security, modularity etc). Due to
> >> this, a lot of things that were happening within a process boundary
> >> happen now across process boundaries over the binder bus. Early on
> >> folks noticed that this caused performance issues without sync flag
> >> being used as a more strong hint. This can happen when there are 2
> >> threads are in different frequency domains on different CPUs and are
> >> communicating over binder, due to this the combined load of both
> >> threads is divided between the individual CPUs and causes them to run
> >> at lower frequency. Where as if they are running together on the same
> >> CPUs, then they would run at a higher frequency and perform better as
> >> their combined load would run at a higher frequency. So a stronger
> >> sync actually helps this case if we're careful about using it when
> >> possible.
> >
> > Sure, but isn't that really a cpufreq issue?  We schedule cross core
> 
> IMO its an issue with the scheduler not being aware of the
> relationship between groups of tasks doing work as a pipeline. Sync
> seems to me one way to communicate that.

It's certainly simple, which is requirement #1.

> > quite aggressively for obvious reasons.  Now on mostly idle handheld
> > devices, you may get better battery life by stacking tasks a bit more,
> > in which case a sync-me-harder flag may be what you really want/need,
> > but with modern CPUs, I'm kinda skeptical of that, would have to see
> > cold hard numbers to become a believer.  Iff deeper cstate etc for
> 
> If you can suggest any tests, I could run them on my Intel machine? By
> the way CPUs on handhelds are pretty modern these days ;-)

Nah, that would be wasting your time doing what I could do myself.

> > longer does make a big difference, I can imagine wakeup time migrate
> > leftward if capacity exists as an "on battery" tactic. (though that
> > thought also invokes some unpleasant bounce fest images)
> 
> I'm assuming you mean that tasks are packed together more closely and
> scheduled on energy aware CPUs at wake up time. This is exactly what
> we do in the Energy aware scheduling (EAS) that ARM has been working
> on and is integrated into the Android kernels but its being done
> whether on battery or plugged in. Also instead of migrating leftward
> or a fixed diretion, it checks for what would the changes in energy be
> based on an "energy model" and the current utilization before deciding
> on whether to wake up on a different CPU. Its also not perfect and is
> an approximation but overall seems to provide good energy savings.

OK, so you're already doing some packing.

Personally, I still think that there's a bit of a disconnect between
cpufreq and scheduler, but that aside, sync was invented for what
you're trying to do. ÂIf you can improve it without wreckage, cool,
generic improvement rocks, so good luck.

	-Mike