On Wed, Apr 13, 2016 at 7:53 PM, Steve Muckle <[email protected]> wrote: > On 04/13/2016 07:45 AM, Rafael J. Wysocki wrote: >>> I'm concerned generally with the latency to react to changes in >>> > required capacity due to remote wakeups, which are quite common on SMP >>> > platforms with shared cache. Unless the hook is called it could take >>> > up to a tick to react AFAICS if the target CPU is running some other >>> > task that does not get preempted by the wakeup. >> >> So the scenario seems to be that CPU A is running task X and CPU B >> wakes up task Y on it remotely, but that task has to wait for CPU A to >> get to it, so you want to increase the frequency of CPU A at the >> wakeup time so as to reduce the time the woken up task has to wait. >> >> In that case task X would not be giving the CPU away (ie. no >> invocations of schedule()) for the whole tick, so it would be >> CPU/memory bound. In that case I would expect CPU A to be running at >> full capacity already unless this is the first tick period in which >> task X behaves this way which looks like a corner case to me. > > This situation is fairly common in bursty workloads (such as UI driven > ones). > >> Moreover, sending an IPI to CPU A in that case looks like the right >> thing to do to me anyway. > > Sorry I didn't follow - sending an IPI to do what exactly? Perform the > wakeup operation on the target CPU?
Basically, to run a frequency update. You can combine that with the wakeup itself, though, I suppose.
