On Tue, Jan 14, 2014 at 04:21:15PM +0000, Morten Rasmussen wrote:

quoted

This appears to be a property of the workload that the scheduler can't really
learn by itself (it can't possibly know, unless told somehow, that t0 is going
to go to sleep shortly after t1 has been started).

It looks like that might be covered by a new thread flag meaning "start my
children on the same CPU".  Or a clone flag meaning "run this child on the same
CPU".

It could work for multithreaded applications, but I'm not sure if it would
work for Android muddleware threads. Android audio playback as described
in another post exhibits a pattern similar to the above. It may not be
possible to have a parent/child setup for the Android audio subsystem
threads that gives the desired behaviour.

We used to have a guestimator at some point that would measure the
overlap (the time we keep running after waking another task), which we
used to auto select WF_SYNC.

The fact that we no longer have this only says that we weren't smart
enough to make it work reliable enough :-)

ISTR there were also people poking at having special FUTEX flags to
indicate such situations, but I can't remember whatever became of that.