From patchwork Wed Apr 15 10:00:24 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Daniel Lezcano X-Patchwork-Id: 6219641 Return-Path: X-Original-To: patchwork-linux-pm@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 9DFEDBF4A6 for ; Wed, 15 Apr 2015 10:01:42 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id C10192037A for ; Wed, 15 Apr 2015 10:01:38 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B7FD220380 for ; Wed, 15 Apr 2015 10:01:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755789AbbDOKB3 (ORCPT ); Wed, 15 Apr 2015 06:01:29 -0400 Received: from mail-wg0-f51.google.com ([74.125.82.51]:36456 "EHLO mail-wg0-f51.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754407AbbDOKAj (ORCPT ); Wed, 15 Apr 2015 06:00:39 -0400 Received: by wgsk9 with SMTP id k9so40807282wgs.3 for ; Wed, 15 Apr 2015 03:00:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to :references; bh=RZAmk7z/rWzeG+tXhKbZUktY37xUdypXGJPHy2abxm4=; b=Jg0iZzWHmu3Cdqfq42buYfQty93LIIC9qsT378rqFCr15h7wqOS8DWWUHZn9lcMdYK aJgNWpdwwgis5UYHYjlpSOz+MzYOvJTOS3FhJjfeQ/JgADdKn36LRgDsNai8PMc2o64G 8WAO6rYutFPHfsMBZT0F73Ln0TqsI1SakZ4xS83EqFkVMEyoBUPD0Dewo4wwqnFyOCiq XDM6R3YytS4HO4YgWTVly18UZF/VmHAjwUBAv+9YNGc/wJ7mNr8IrpeZnTNWf44aDyU9 WavXuYEgUKfDPGzamqLDKn+rdJKAO5ahqOJh7l/cXLwCM9yTekjYi6aXBsEqLWXxZw9k AifQ== X-Gm-Message-State: ALoCoQna6GD8KGynq3IHTYitoKSOOWhM0cAa4MbYwOt27llwpKMEp1bEdvUo8qhXl1a35NTAbX57 X-Received: by 10.194.221.100 with SMTP id qd4mr46822377wjc.113.1429092037041; Wed, 15 Apr 2015 03:00:37 -0700 (PDT) Received: from mai.lan (135-224-190-109.dsl.ovh.fr. [109.190.224.135]) by mx.google.com with ESMTPSA id z13sm5233590wjr.44.2015.04.15.03.00.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 15 Apr 2015 03:00:36 -0700 (PDT) From: Daniel Lezcano To: peterz@infradead.org, rjw@rjwysocki.net Cc: linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, nicolas.pitre@linaro.org, Ingo Molnar Subject: [PATCH 3/3] sched: fair: Fix wrong idle timestamp usage Date: Wed, 15 Apr 2015 12:00:24 +0200 Message-Id: <1429092024-20498-3-git-send-email-daniel.lezcano@linaro.org> X-Mailer: git-send-email 1.9.1 In-Reply-To: <1429092024-20498-1-git-send-email-daniel.lezcano@linaro.org> References: <1429092024-20498-1-git-send-email-daniel.lezcano@linaro.org> Sender: linux-pm-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-pm@vger.kernel.org X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP The find_idlest_cpu is assuming the rq->idle_stamp information reflects when the cpu entered the idle state. This is wrong as the cpu may exit and enter the idle state several times without the rq->idle_stamp being updated. We have two informations here: * rq->idle_stamp gives when the idle task has been scheduled * idle->idle_stamp gives when the cpu entered the idle state The patch fixes that by using the latter information and fallbacks to the rq's timestamp when the idle state is not accessible Signed-off-by: Daniel Lezcano --- kernel/sched/fair.c | 42 ++++++++++++++++++++++++++++-------------- 1 file changed, 28 insertions(+), 14 deletions(-) diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c index 46855d0..b44f1ad 100644 --- a/kernel/sched/fair.c +++ b/kernel/sched/fair.c @@ -4704,21 +4704,35 @@ find_idlest_cpu(struct sched_group *group, struct task_struct *p, int this_cpu) if (idle_cpu(i)) { struct rq *rq = cpu_rq(i); struct cpuidle_state *idle = idle_get_state(rq); - if (idle && idle->exit_latency < min_exit_latency) { - /* - * We give priority to a CPU whose idle state - * has the smallest exit latency irrespective - * of any idle timestamp. - */ - min_exit_latency = idle->exit_latency; - latest_idle_timestamp = rq->idle_stamp; - shallowest_idle_cpu = i; - } else if ((!idle || idle->exit_latency == min_exit_latency) && - rq->idle_stamp > latest_idle_timestamp) { + + if (idle) { + if (idle->exit_latency < min_exit_latency) { + /* + * We give priority to a CPU + * whose idle state has the + * smallest exit latency + * irrespective of any idle + * timestamp. + */ + min_exit_latency = idle->exit_latency; + latest_idle_timestamp = idle->idle_stamp; + shallowest_idle_cpu = i; + } else if (idle->exit_latency == min_exit_latency && + idle->idle_stamp > latest_idle_timestamp) { + /* + * If the CPU is in the same + * idle state, choose the more + * recent one as it might have + * a warmer cache + */ + latest_idle_timestamp = idle->idle_stamp; + shallowest_idle_cpu = i; + } + } else if (rq->idle_stamp > latest_idle_timestamp) { /* - * If equal or no active idle state, then - * the most recently idled CPU might have - * a warmer cache. + * If no active idle state, then the + * most recent idled CPU might have a + * warmer cache */ latest_idle_timestamp = rq->idle_stamp; shallowest_idle_cpu = i;