Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754042AbcDMTjq (ORCPT ); Wed, 13 Apr 2016 15:39:46 -0400 Received: from mail-lf0-f65.google.com ([209.85.215.65]:33282 "EHLO mail-lf0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750705AbcDMTjn (ORCPT ); Wed, 13 Apr 2016 15:39:43 -0400 MIME-Version: 1.0 In-Reply-To: <570E879A.90008@linaro.org> References: <56F97856.4040804@arm.com> <56F98832.3030207@linaro.org> <20160330193544.GD407@worktop> <56FC807C.80204@linaro.org> <20160331073743.GF3408@twins.programming.kicks-ass.net> <56FD95EE.6090007@linaro.org> <20160401092019.GN3430@twins.programming.kicks-ass.net> <570BFAE2.4080301@linaro.org> <20160412193857.GA22643@graphite.smuckle.net> <570E879A.90008@linaro.org> Date: Wed, 13 Apr 2016 21:39:40 +0200 X-Google-Sender-Auth: WT2TvxR7DflQggiRsrDSHvG2IEU Message-ID: Subject: Re: [PATCH 1/2] sched/fair: move cpufreq hook to update_cfs_rq_load_avg() From: "Rafael J. Wysocki" To: Steve Muckle Cc: "Rafael J. Wysocki" , Peter Zijlstra , Dietmar Eggemann , Ingo Molnar , Linux Kernel Mailing List , "linux-pm@vger.kernel.org" , Vincent Guittot , Morten Rasmussen , Juri Lelli , Patrick Bellasi , Michael Turquette Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1509 Lines: 30 On Wed, Apr 13, 2016 at 7:53 PM, Steve Muckle 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.