Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932887AbcDTH7s (ORCPT ); Wed, 20 Apr 2016 03:59:48 -0400 Received: from mail-oi0-f67.google.com ([209.85.218.67]:34593 "EHLO mail-oi0-f67.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754532AbcDTH7o (ORCPT ); Wed, 20 Apr 2016 03:59:44 -0400 MIME-Version: 1.0 In-Reply-To: <1460555812-25375-3-git-send-email-fweisbec@gmail.com> References: <1460555812-25375-1-git-send-email-fweisbec@gmail.com> <1460555812-25375-3-git-send-email-fweisbec@gmail.com> Date: Wed, 20 Apr 2016 15:59:43 +0800 Message-ID: Subject: Re: [PATCH 2/3] sched: Correctly handle nohz ticks cpu load accounting From: Wanpeng Li To: Frederic Weisbecker Cc: Peter Zijlstra , LKML , Byungchul Park , Chris Metcalf , Thomas Gleixner , Luiz Capitulino , Christoph Lameter , "Paul E . McKenney" , Mike Galbraith , Rik van Riel , Ingo Molnar 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: 1324 Lines: 25 Hi Frederic, 2016-04-13 21:56 GMT+08:00 Frederic Weisbecker : > Ticks can happen while the CPU is in dynticks-idle or dynticks-singletask > mode. In fact "nohz" or "dynticks" only mean that we exit the periodic > mode and we try to minimize the ticks as much as possible. The nohz > subsystem uses a confusing terminology with the internal state > "ts->tick_stopped" which is also available through its public interface > with tick_nohz_tick_stopped(). This is a misnomer as the tick is instead > reduced with the best effort rather than stopped. In the best case the > tick can indeed be actually stopped but there is no guarantee about that. > If a timer needs to fire one second later, a tick will fire while the > CPU is in nohz mode and this is a very common scenario. > > Now this confusion happens to be a problem with cpu load updates: > cpu_load_update_active() doesn't handle nohz ticks correctly because it > assumes that ticks are completely stopped in nohz mode and that > cpu_load_update_active() can't be called in dynticks mode. When that > happens, the whole previous tickless load is ignored and the function > just records the load for the current tick, ignoring potentially long > idle periods behind. This is for one timer interrupt per second scenario, right? Regards, Wanpeng Li