On 31 March 2016 at 11:34, Peter Zijlstra <[email protected]> wrote: > 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.
yes, i was speaking about a remote wakeup. In the ttwu_queue_remote, there is a call to smp_send_reschedule. Is there another way to add a remote task in the wake list ? > > And we really don't want to carry the 'has util increased' information > all the way down to where we make that decision. yes i agree
