Received: by 10.213.65.68 with SMTP id h4csp1575432imn; Mon, 19 Mar 2018 07:51:07 -0700 (PDT) X-Google-Smtp-Source: AG47ELtGny7itR3YJkRyhr66QnhWWd+NQvEqXTHeEGdUBMPPsr0isXWmyRnZzawQ2LTGG/Zn+bai X-Received: by 10.98.196.153 with SMTP id h25mr2217258pfk.111.1521471067232; Mon, 19 Mar 2018 07:51:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521471067; cv=none; d=google.com; s=arc-20160816; b=m2yIZOwLyAv6fItT+lLqPiBLs+vpBRZnamPVsjr+WuY9nN3xc5Ykn0wyl1QbOoMpnk 29C1DnSl7nmmF+B18F8luPkA16R8yfxrjbovB35EZxwJ2H35uuADsi1pM/ty+w2XM5BL X9nKHKnjv+cG6iOORj0puwAjLeTUeDaGAZPocA/UKAaRI/j4kZ9rfkWboIvn+gf1bddb 66Yjw8bWW1/7s9r5Kold//6gJukvDWYeXhFmmjVOAcjXjFv9cvA2UYp/XQiQt4giki/g M9jdhrabZaD3+UQZX0WS47g5uqZzZl+6PqEn7nNXPfdL/A2qoSH7qyqRqPbNbUaSjBqC xiVQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=a8C2DBercbDfywf8An1qGFmP803PCym1idyl5ta4Fms=; b=UovGF1fgEf12C/tsuiCcNr57zrTr7FFqhBZIitY84f3zUHjDqEFdr49nK6zdZC9bOQ /ql+XqJIsZyNIPnhL9vwboi1uMQer4ZV7Xvj0r4i+U5h9CAsJGKjCDaGohIAr1+6oafN 6dBW/b4zYPbs7I2h8bSnn98ltTH8a1/0uY5xa0G7hxqnEaMvq0IgRNF+nJ0g/XXCYwzT gFzKNX2oag01MvQtnU9BF/lgujjerBavDWOgoACmmPYGAhduc67HBD93ySikAP4PmAZp aVj9tSDs3L9mfO7BI4llG+bkJCStmuDK7D4r+/9tA4YhGGJRntWlH74sM43P8rfNgy6s eOvw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=jDo4dU6b; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id o12si91605pgr.99.2018.03.19.07.50.51; Mon, 19 Mar 2018 07:51:07 -0700 (PDT) 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; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=jDo4dU6b; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932475AbeCSMbf (ORCPT + 99 others); Mon, 19 Mar 2018 08:31:35 -0400 Received: from bombadil.infradead.org ([198.137.202.133]:47848 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750739AbeCSMbe (ORCPT ); Mon, 19 Mar 2018 08:31:34 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=a8C2DBercbDfywf8An1qGFmP803PCym1idyl5ta4Fms=; b=jDo4dU6bxPS1QQVa3ByQ2vjaQ 4lRC+sVy5/1u5ACOkYAiOtCNBGIgr7QoqogvGe6r+UTTP0cIGRvwgd9DrpKjwY63yaemKZi63BRL3 /d9gg9gcWu9BUNr9LoQQOPLp0+IkX6l8RlHOZ/hOyfXNNWZIzyBQtBpZ8jY8LDb9wq7+uNbFcI/dM 0XgDS1ocNvaycfUTpnXIV4BhB5aIeaICjD5GJxtT/KJ0w4eegmZ96ynf3PgeO9jpTSggTBuhs+3pK /FU2s07jCl1x1PQP7gGYLEe+VXx7l0E2a6yekBV6mJ9/CxtVY9bOKMOEbrOqFDwzjQ8q81625eN5y BmB5G0nkg==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by bombadil.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1extwe-0003Kh-5i; Mon, 19 Mar 2018 12:31:20 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 5BB092029F860; Mon, 19 Mar 2018 13:31:17 +0100 (CET) Date: Mon, 19 Mar 2018 13:31:17 +0100 From: Peter Zijlstra To: "Rafael J. Wysocki" Cc: Doug Smythies , Thomas Ilsche , Linux PM , Frederic Weisbecker , Thomas Gleixner , Paul McKenney , Rik van Riel , Aubrey Li , Mike Galbraith , LKML Subject: Re: [RFT][PATCH v5 0/7] sched/cpuidle: Idle loop rework Message-ID: <20180319123117.GI4043@hirez.programming.kicks-ass.net> References: <2142751.3U6XgWyF8u@aspire.rjw.lan> <001a01d3be0a$ad3a0ed0$07ae2c70$@net> <2043615.lCdO10SMaB@aspire.rjw.lan> <20180319104900.GH4043@hirez.programming.kicks-ass.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.3 (2018-01-21) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Mar 19, 2018 at 12:36:52PM +0100, Rafael J. Wysocki wrote: > > My brain is just not willing to understand how that work this morning. > > Also it sounds really dodgy. > > Well, I guess I can't really explain it better. :-) I'll try again once my brain decides to wake up. > The reason why this works better than the original v5 is because of > how menu_update() works AFAICS. I'll have to go read that first then. > > + if (!tick_nohz_idle_got_tick()) { > > + /* > > + * Give the governor an opportunity to reflect on the outcome > > + */ > > + cpuidle_reflect(dev, entered_state); > > + } > > So I guess the idea is to only invoke menu_update() if the CPU was not > woken up by the tick, right? > > I would check that in menu_reflect() (as the problem is really with > the menu governor and not general). > > Also, do we really want to always disregard wakeups from the tick? > > Say, if the governor predicted idle duration of a few microseconds and > the CPU is woken up by the tick, we want it to realize that it was way > off, don't we? The way I look at it is that we should always disregard the tick for wakeups. Such that we can make an unbiased decision on disabling it. If the above simple method is the best way to achieve that, probably not. Because now we 'loose' the idle time, instead of accumulating it. > > } > > > > exit_idle: > > --- a/kernel/time/tick-sched.c > > +++ b/kernel/time/tick-sched.c > > @@ -996,6 +996,21 @@ void tick_nohz_idle_enter(void) > > local_irq_enable(); > > } > > > > +bool tick_nohz_idle_got_tick(void) > > +{ > > + struct tick_sched *ts; > > + bool got_tick = false; > > + > > + ts = this_cpu_ptr(&tick_cpu_sched); > > + > > + if (ts->inidle == 2) { > > + got_tick = true; > > + ts->inidle = 1; > > + } > > + > > + return got_tick; > > +} > > Looks simple enough. :-) Yes, the obvious fail is that it will not be able to tell if it was the only wakeup source. Suppose two interrupts fire, the tick and something else, the above will disregard the idle time, even though it maybe should not have. > > + > > /** > > * tick_nohz_irq_exit - update next tick event from interrupt exit > > * > > @@ -1142,6 +1157,9 @@ static void tick_nohz_handler(struct clo > > struct pt_regs *regs = get_irq_regs(); > > ktime_t now = ktime_get(); > > > > + if (ts->inidle) > > + ts->inidle = 2; > > + > > dev->next_event = KTIME_MAX; > > > > tick_sched_do_timer(now); > > @@ -1239,6 +1257,9 @@ static enum hrtimer_restart tick_sched_t > > struct pt_regs *regs = get_irq_regs(); > > ktime_t now = ktime_get(); > > > > + if (ts->inidle) > > + ts->inidle = 2; > > + > > Why do we need to do it here? > > > tick_sched_do_timer(now); > > > > /* Both are tick handlers, one low-res one high-res. The idea it that the tick flips the ts->inidle thing from 1->2, which then allows *got_tick() to detect if we had a tick for wakeup.