Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1758848AbbKSRom (ORCPT ); Thu, 19 Nov 2015 12:44:42 -0500 Received: from mga01.intel.com ([192.55.52.88]:37364 "EHLO mga01.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751702AbbKSRok (ORCPT ); Thu, 19 Nov 2015 12:44:40 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.20,318,1444719600"; d="scan'208";a="689673510" Date: Thu, 19 Nov 2015 09:43:39 -0800 From: Jacob Pan To: Jacob Pan Cc: Thomas Gleixner , Peter Zijlstra , Ingo Molnar , John Stultz , LKML , Arjan van de Ven , Srinivas Pandruvada , Len Brown , Rafael Wysocki , Eduardo Valentin , Paul Turner , Josh Triplett , "Paul E. McKenney" Subject: Re: [PATCH 2/4] timer: relax tick stop in idle entry Message-ID: <20151119094339.35e4b889@icelake> In-Reply-To: <20151116160910.3811c8ca@icelake> References: <1447444387-23525-1-git-send-email-jacob.jun.pan@linux.intel.com> <1447444387-23525-3-git-send-email-jacob.jun.pan@linux.intel.com> <20151113142438.3144d47d@icelake> <20151116135126.5a50e45d@icelake> <20151116160910.3811c8ca@icelake> Organization: OTC X-Mailer: Claws Mail 3.9.3 (GTK+ 2.24.23; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2072 Lines: 55 On Mon, 16 Nov 2015 16:09:10 -0800 Jacob Pan wrote: > > > For the second case, which is much more rare, I think we do have > > > next timer exactly one tick away. Just don't know why tick will > > > continue into idle loop. > > > > Well, it should not be hard to figure that out. There are not so > > many checks involved when tick_nohz_irq_exit() is called. > Thanks for the tip, I found the cause is in > int idle_cpu(int cpu) > { > if (rq->nr_running) > return 0; > > Since we only take into account of cfs_rq runnable taking over > cfs_rq->nr_running when forced_idle is set. I am not sure what is the best solution. It seems I can add additional checks like this. --- a/kernel/sched/core.c +++ b/kernel/sched/core.c @@ -3520,9 +3520,14 @@ int idle_cpu(int cpu) if (rq->curr != rq->idle) return 0; - if (rq->nr_running) - return 0; - + if (rq->nr_running) { + /* if cfs_rq is in forced idle, nr_running could be nonzero but still in idle */ + if ((rq->nr_running != rq->cfs.h_nr_running) || + cfs_rq_runnable(&rq->cfs)) + return 0; + } To recap the problem statement. 1. When entering idle loop tick_nohz_stop_sched_tick() checks if the next timer interrupt is exactly one tick away. if so, it will not stop it to avoid threshing timer disable and enable. 2. so it relies on the next round tick_nohz_irq_exit() to have another chance to stop the tick 3. with idle injection rq->nr_running could be nonzero when in idle 4. tick_nohz_irq_exit() will not be called if !idle_cpu() However, idle_cpu() is used by many other callers, e.g. load balance. Do we want to consider forced idle in those cases? Or we can forgo this case and ignore it? Jacob -- 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/