On Thu, Mar 31, 2016 at 11:27:22AM +0200, Vincent Guittot wrote: > On 30 March 2016 at 21:35, Peter Zijlstra <[email protected]> wrote: > > On Mon, Mar 28, 2016 at 12:38:26PM -0700, Steve Muckle wrote: > >> Without covering all the paths where CFS utilization changes it's > >> possible to have to wait up to a tick to act on some changes, since the > >> tick is the only guaranteed regularly-occurring instance of the hook. > >> That's an unacceptable amount of latency IMO... > > > > Note that even with your patches that might still be the case. Remote > > wakeups might not happen on the destination CPU at all, so it might not > > be until the next tick (which always happens locally) that we'll > > 'observe' the utilization change brought with the wakeups. > > > > We could force all the remote wakeups to IPI the destination CPU, but > > that comes at a significant performance cost. > > Isn't a reschedule ipi already sent in this case ?
In what case? Assuming you talk about a remove wakeup, no. Only if that wakeup results in a preemption, which isn't a given. And we really don't want to carry the 'has util increased' information all the way down to where we make that decision.
