From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
        id S1752170AbdBOQQY (ORCPT <rfc822;w@1wt.eu>);
        Wed, 15 Feb 2017 11:16:24 -0500
Received: from mail-wr0-f174.google.com ([209.85.128.174]:36670 "EHLO
        mail-wr0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1751598AbdBOQQW (ORCPT
        <rfc822;linux-kernel@vger.kernel.org>);
        Wed, 15 Feb 2017 11:16:22 -0500
Date: Wed, 15 Feb 2017 16:16:19 +0000
From: Matt Fleming <matt@codeblueprint.co.uk>
To: Frederic Weisbecker <fweisbec@gmail.com>
Cc: Peter Zijlstra <peterz@infradead.org>, Ingo Molnar <mingo@kernel.org>,
        linux-kernel@vger.kernel.org,
        Mike Galbraith <umgwanakikbuti@gmail.com>,
        Morten Rasmussen <morten.rasmussen@arm.com>, stable@vger.kernel.org,
        Vincent Guittot <vincent.guittot@linaro.org>
Subject: Re: [PATCH] sched/loadavg: Avoid loadavg spikes caused by delayed
 NO_HZ accounting
Message-ID: <20170215161619.GD28416@codeblueprint.co.uk>
References: <20170208132924.3038-1-matt@codeblueprint.co.uk>
 <20170215151210.GA6691@lerouge>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20170215151210.GA6691@lerouge>
User-Agent: Mutt/1.5.24+41 (02bc14ed1569) (2015-08-30)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, 15 Feb, at 04:12:11PM, Frederic Weisbecker wrote:
> On Wed, Feb 08, 2017 at 01:29:24PM +0000, Matt Fleming wrote:
> > The calculation for the next sample window when exiting NOH_HZ idle
> > does not handle the fact that we may not have reached the next sample
> > window yet
> 
> That sentence is hard to parse, it took me some time to figure out that
> those two "next sample window" may not refer to the same thing.
 
Yeah, it's not the most lucid thing I've ever written.

> Maybe it would be clearer with something along the lines of:
> 
> "The calculation for the next sample window when exiting NO_HZ
>  does not handle the fact that we may not have crossed any sample
>  window during the NO_HZ period."
 
Umm... this isn't the problem. In fact, it's the opposite.

The problem is that if we *did* cross a sample window while in NO_HZ,
then when we exit the pending window may be far enough into the future
that all we need to do is update this_rq->calc_load_update.

> > If we wake from NO_HZ idle after the pending this_rq->calc_load_update
> > window time when we want idle but before the next sample window
> 
> That too was hard to understand. How about:
> 
> "If we enter in NO_HZ mode after a pending this_rq->calc_load_update
>  and we exit from NO_HZ mode before the forthcoming sample window, ..."
 
You've got this backwards again. We enter NO_HZ before the pending
window, not after.