From patchwork Thu Jan 23 05:52:32 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Viresh Kumar X-Patchwork-Id: 23565 Return-Path: X-Original-To: linaro@patches.linaro.org Delivered-To: linaro@patches.linaro.org Received: from mail-ve0-f199.google.com (mail-ve0-f199.google.com [209.85.128.199]) by ip-10-151-82-157.ec2.internal (Postfix) with ESMTPS id CCEA4218CB for ; Thu, 23 Jan 2014 05:52:42 +0000 (UTC) Received: by mail-ve0-f199.google.com with SMTP id oy12sf2465466veb.2 for ; Wed, 22 Jan 2014 21:52:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:delivered-to:mime-version:in-reply-to:references :date:message-id:subject:from:to:cc:sender:precedence:list-id :x-original-sender:x-original-authentication-results:mailing-list :list-post:list-help:list-archive:list-unsubscribe:content-type; bh=oDxQmt1QV1K2+JvSMjytrgqCC3xdz50TS2/9d7QdoOE=; b=RhQR3sF+RE47KxNXhwmS4T9aLogys89rsgUUMnsbiO/kNDAEZx/tomCFNqcfe3tW60 TCxh6A7tROwrsClzEDWAech6c/51RdlhW3pC63MJLXXEGIUDyO0Vt5u75M+azC3QUJc4 qyscMU/L3JJGodUvRoJqDQQbHr0bFujJ5THHBpZGGxZ2TzC90U5HB8uB1ncQqDIbr7Ie oSEyIIAgCj8czMYmiTe79nIuOTlmoEEMB0X2Po9uYbFvmYw0hh5KMD9ASa2FKrz9be84 dVjIOs3nTnrhtT2Q9bmm9z21YvLiMRZKzuSpNcGwCbnIioGHyfMr3SAvhT5rGbMLIGss H8jg== X-Gm-Message-State: ALoCoQmU+H4T65wg07fHhGG1kkdMGOT+tFUFrWb8vzKAmw1CM/C5vq34Ncenpd0aRNmijtauEntt X-Received: by 10.58.95.1 with SMTP id dg1mr2339123veb.29.1390456361862; Wed, 22 Jan 2014 21:52:41 -0800 (PST) X-BeenThere: patchwork-forward@linaro.org Received: by 10.49.106.132 with SMTP id gu4ls214188qeb.8.gmail; Wed, 22 Jan 2014 21:52:41 -0800 (PST) X-Received: by 10.58.24.196 with SMTP id w4mr20214vef.48.1390456361695; Wed, 22 Jan 2014 21:52:41 -0800 (PST) Received: from mail-ve0-f180.google.com (mail-ve0-f180.google.com [209.85.128.180]) by mx.google.com with ESMTPS id i3si6054359vcp.127.2014.01.22.21.52.41 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 22 Jan 2014 21:52:41 -0800 (PST) Received-SPF: neutral (google.com: 209.85.128.180 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) client-ip=209.85.128.180; Received: by mail-ve0-f180.google.com with SMTP id db12so826872veb.39 for ; Wed, 22 Jan 2014 21:52:41 -0800 (PST) X-Received: by 10.221.3.70 with SMTP id nx6mr20418vcb.45.1390456361601; Wed, 22 Jan 2014 21:52:41 -0800 (PST) X-Forwarded-To: patchwork-forward@linaro.org X-Forwarded-For: patch@linaro.org patchwork-forward@linaro.org Delivered-To: patch@linaro.org Received: by 10.220.174.196 with SMTP id u4csp1931vcz; Wed, 22 Jan 2014 21:52:41 -0800 (PST) X-Received: by 10.68.223.9 with SMTP id qq9mr6176406pbc.58.1390456360585; Wed, 22 Jan 2014 21:52:40 -0800 (PST) Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id pk8si12653494pab.10.2014.01.22.21.52.39; Wed, 22 Jan 2014 21:52:39 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752806AbaAWFwe (ORCPT + 27 others); Thu, 23 Jan 2014 00:52:34 -0500 Received: from mail-ob0-f170.google.com ([209.85.214.170]:37945 "EHLO mail-ob0-f170.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751718AbaAWFwd (ORCPT ); Thu, 23 Jan 2014 00:52:33 -0500 Received: by mail-ob0-f170.google.com with SMTP id va2so1578726obc.29 for ; Wed, 22 Jan 2014 21:52:32 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.142.229 with SMTP id rz5mr5161843obb.12.1390456352589; Wed, 22 Jan 2014 21:52:32 -0800 (PST) Received: by 10.182.28.168 with HTTP; Wed, 22 Jan 2014 21:52:32 -0800 (PST) In-Reply-To: References: Date: Thu, 23 Jan 2014 11:22:32 +0530 Message-ID: Subject: Re: Is it ok for deferrable timer wakeup the idle cpu? From: Viresh Kumar To: Lei Wen Cc: Thomas Gleixner , LKML , Frederic Weisbecker , Lists linaro-kernel , "linux-pm@vger.kernel.org" , "Rafael J. Wysocki" Sender: linux-kernel-owner@vger.kernel.org Precedence: list List-ID: X-Mailing-List: linux-kernel@vger.kernel.org X-Removed-Original-Auth: Dkim didn't pass. X-Original-Sender: viresh.kumar@linaro.org X-Original-Authentication-Results: mx.google.com; spf=neutral (google.com: 209.85.128.180 is neither permitted nor denied by best guess record for domain of patch+caf_=patchwork-forward=linaro.org@linaro.org) smtp.mail=patch+caf_=patchwork-forward=linaro.org@linaro.org Mailing-list: list patchwork-forward@linaro.org; contact patchwork-forward+owners@linaro.org X-Google-Group-Id: 836684582541 List-Post: , List-Help: , List-Archive: List-Unsubscribe: , On 23 January 2014 11:11, Lei Wen wrote: > On Wed, Jan 22, 2014 at 10:07 PM, Thomas Gleixner wrote: >> On Wed, 22 Jan 2014, Lei Wen wrote: >>> Recently I want to do the experiment for cpu isolation over 3.10 kernel. >>> But I find the isolated one is periodically waken up by IPI interrupt. >>> >>> By checking the trace, I find those IPI is generated by add_timer_on, >>> which would calls wake_up_nohz_cpu, and wake up the already idle cpu. >>> >>> With further checking, I find this timer is added by on_demand governor of >>> cpufreq. It would periodically check each cores' state. >>> The problem I see here is cpufreq_governor using INIT_DEFERRABLE_WORK >>> as the tool, while timer is made as deferrable anyway. >>> And what is more that cpufreq checking is very frequent. In my case, the >>> isolated cpu is wakenup by IPI every 5ms. >>> >>> So why kernel need to wake the remote processor when mount the deferrable >>> timer? As per my understanding, we'd better keep cpu as idle when use >>> the deferrable timer. >> >> Indeed, we can avoid the wakeup of the remote cpu when the timer is >> deferrable. > > Glad to hear that we could fix this unwanted wakeup. > Do you have related patches already? > >> >> Though you really want to figure out why the cpufreq governor is >> arming timers on other cores every 5ms. That smells like an utterly >> stupid approach. > > Not sure why cpufreq choose such frequent profiling over each cpu. > As my understanding, since kernel is smp, launching profiler over one cpu > would be enough... Hi Guys, So the first question is why cpufreq needs it and is it really stupid? Yes, it is stupid but that's how its implemented since a long time. It does so to get data about the load on CPUs, so that freq can be scaled up/down. Though there is a solution in discussion currently, which will take inputs from scheduler and so these background timers would go away. But we need to wait until that time. Now, why do we need that for every cpu, while that for a single cpu might be enough? The answer is cpuidle here: What if the cpu responsible for running timer goes to sleep? Who will evaluate the load then? And if we make this timer run on one cpu in non-deferrable mode then that cpu would be waken up again and again from idle. So, it was decided to have a per-cpu deferrable timer. Though to improve efficiency, once it is fired on any cpu, timer for all other CPUs are rescheduled, so that they don't fire before 5ms (sampling time).. I think below diff might get this fixed for you, though I am not sure if it breaks something else. Probably Thomas/Frederic can answer here. If this looks fine I will send it formally again: --- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ diff --git a/kernel/timer.c b/kernel/timer.c index accfd24..3a2c7fa 100644 --- a/kernel/timer.c +++ b/kernel/timer.c @@ -940,7 +940,8 @@ void add_timer_on(struct timer_list *timer, int cpu) * makes sure that a CPU on the way to stop its tick can not * evaluate the timer wheel. */ - wake_up_nohz_cpu(cpu); + if (!tbase_get_deferrable(timer->base)) + wake_up_nohz_cpu(cpu); spin_unlock_irqrestore(&base->lock, flags); } EXPORT_SYMBOL_GPL(add_timer_on);