From: Peter Zijlstra <peterz@infradead.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
Cc: Doug Smythies <dsmythies@telus.net>,
Thomas Ilsche <thomas.ilsche@tu-dresden.de>,
Linux PM <linux-pm@vger.kernel.org>,
Frederic Weisbecker <fweisbec@gmail.com>,
Thomas Gleixner <tglx@linutronix.de>,
Paul McKenney <paulmck@linux.vnet.ibm.com>,
Rik van Riel <riel@surriel.com>,
Aubrey Li <aubrey.li@linux.intel.com>,
Mike Galbraith <mgalbraith@suse.de>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [RFT][PATCH v5 0/7] sched/cpuidle: Idle loop rework
Date: Mon, 19 Mar 2018 13:31:17 +0100 [thread overview]
Message-ID: <20180319123117.GI4043@hirez.programming.kicks-ass.net> (raw)
In-Reply-To: <CAJZ5v0iE-LZ9TyahT7rsJW8zBnKfgnx6C-=SYJrpzspTQXV4zg@mail.gmail.com>
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.
next prev parent reply other threads:[~2018-03-19 12:31 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-15 21:59 [RFT][PATCH v5 0/7] sched/cpuidle: Idle loop rework Rafael J. Wysocki
2018-03-15 22:03 ` [RFT][PATCH v5 1/7] time: tick-sched: Reorganize idle tick management code Rafael J. Wysocki
2018-03-15 22:05 ` [RFT][PATCH v5 2/7] sched: idle: Do not stop the tick upfront in the idle loop Rafael J. Wysocki
2018-03-15 22:07 ` [RFT][PATCH v5 3/7] sched: idle: Do not stop the tick before cpuidle_idle_call() Rafael J. Wysocki
2018-03-15 22:11 ` [RFT][PATCH v5 4/7] cpuidle: Return nohz hint from cpuidle_select() Rafael J. Wysocki
2018-03-19 9:11 ` Peter Zijlstra
2018-03-19 9:39 ` Rafael J. Wysocki
2018-03-15 22:13 ` [RFT][PATCH v5 5/7] sched: idle: Select idle state before stopping the tick Rafael J. Wysocki
2018-03-15 22:16 ` [RFT][PATCH v5 6/7] cpuidle: menu: Refine idle state selection for running tick Rafael J. Wysocki
2018-03-19 9:45 ` Peter Zijlstra
2018-03-19 9:49 ` Rafael J. Wysocki
2018-03-15 22:19 ` [RFT][PATCH v5 7/7] cpuidle: menu: Avoid selecting shallow states with stopped tick Rafael J. Wysocki
2018-03-19 12:47 ` Thomas Ilsche
2018-03-19 18:21 ` Doug Smythies
2018-03-20 17:15 ` Doug Smythies
2018-03-20 17:28 ` Rafael J. Wysocki
2018-03-17 12:42 ` [RFT][PATCH v5 0/7] sched/cpuidle: Idle loop rework Thomas Ilsche
2018-03-17 16:11 ` Doug Smythies
2018-03-18 11:00 ` Rafael J. Wysocki
2018-03-18 16:15 ` Rafael J. Wysocki
2018-03-19 10:49 ` Peter Zijlstra
2018-03-19 11:36 ` Rafael J. Wysocki
2018-03-19 11:58 ` Rafael J. Wysocki
2018-03-19 12:31 ` Peter Zijlstra [this message]
2018-03-20 10:01 ` Thomas Ilsche
2018-03-20 10:49 ` Rafael J. Wysocki
2018-03-20 17:15 ` Doug Smythies
2018-03-20 21:03 ` Doug Smythies
2018-03-21 6:33 ` Rafael J. Wysocki
2018-03-21 13:51 ` Doug Smythies
2018-03-21 13:58 ` Rafael J. Wysocki
2018-03-18 15:30 ` Doug Smythies
2018-03-18 16:06 ` Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180319123117.GI4043@hirez.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=aubrey.li@linux.intel.com \
--cc=dsmythies@telus.net \
--cc=fweisbec@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@vger.kernel.org \
--cc=mgalbraith@suse.de \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rafael@kernel.org \
--cc=riel@surriel.com \
--cc=tglx@linutronix.de \
--cc=thomas.ilsche@tu-dresden.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.