All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mike Galbraith <efault@gmx.de>
To: "Li, Aubrey" <aubrey.li@linux.intel.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Aubrey Li <aubrey.li@intel.com>
Cc: tglx@linutronix.de, peterz@infradead.org, len.brown@intel.com,
	ak@linux.intel.com, tim.c.chen@linux.intel.com,
	linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [RFC PATCH v2 4/8] tick/nohz: keep tick on for a fast idle
Date: Mon, 16 Oct 2017 08:25:35 +0200	[thread overview]
Message-ID: <1508135135.8087.17.camel@gmx.de> (raw)
In-Reply-To: <c64ed43d-8afe-7317-e31f-a7a5eef914d1@linux.intel.com>

On Mon, 2017-10-16 at 13:34 +0800, Li, Aubrey wrote:
> On 2017/10/16 12:45, Mike Galbraith wrote:
> > On Mon, 2017-10-16 at 11:26 +0800, Li, Aubrey wrote:
> >>
> >> I'll try to move quiet_vmstat() into the normal idle branch if this patch series
> >> are reasonable. Is fast_idle a good indication for it?
> > 
> > see x86_tip 62cb1188ed86 sched/idle: Move quiet_vmstate() into the NOHZ code
> 
> It looks like this commit makes tick stop critical as it can be invoked in interrupt
> exit path?

do_idle() ain't critical?  It is in my book.  Hopefully, you're about
to make that idle_stat.fast_idle thingy liberal enough that we cease
mucking about with the tick on every microscopic idle (and I can then
trash my years old local patch to avoid needlessly eating that cost).

	-Mike

  reply	other threads:[~2017-10-16  6:26 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-09-30  7:20 [RFC PATCH v2 0/8] Introduct cpu idle prediction functionality Aubrey Li
2017-09-30  7:20 ` [RFC PATCH v2 1/8] cpuidle: menu: extract " Aubrey Li
2017-10-14  0:26   ` Rafael J. Wysocki
2017-10-16  2:46     ` Li, Aubrey
2017-09-30  7:20 ` [RFC PATCH v2 2/8] cpuidle: record the overhead of idle entry Aubrey Li
2017-10-14  0:35   ` Rafael J. Wysocki
2017-10-16  3:11     ` Li, Aubrey
2017-10-17  0:05       ` Rafael J. Wysocki
2017-10-17  7:04         ` Li, Aubrey
2017-09-30  7:20 ` [RFC PATCH v2 3/8] cpuidle: add a new predict interface Aubrey Li
2017-10-14  0:45   ` Rafael J. Wysocki
2017-10-16  8:04     ` Li, Aubrey
2017-10-14  1:27   ` Rafael J. Wysocki
2017-10-16  9:52     ` Li, Aubrey
2017-09-30  7:20 ` [RFC PATCH v2 4/8] tick/nohz: keep tick on for a fast idle Aubrey Li
2017-10-14  0:51   ` Rafael J. Wysocki
2017-10-16  3:26     ` Li, Aubrey
2017-10-16  4:45       ` Mike Galbraith
2017-10-16  5:34         ` Li, Aubrey
2017-10-16  6:25           ` Mike Galbraith [this message]
2017-10-16  6:31             ` Li, Aubrey
2017-09-30  7:20 ` [RFC PATCH v2 5/8] timers: keep sleep length updated as needed Aubrey Li
2017-10-14  0:56   ` Rafael J. Wysocki
2017-10-16  6:46     ` Li, Aubrey
2017-10-16 23:58       ` Rafael J. Wysocki
2017-10-17  6:10         ` Li, Aubrey
2017-09-30  7:20 ` [RFC PATCH v2 6/8] cpuidle: make fast idle threshold tunable Aubrey Li
2017-10-14  0:59   ` Rafael J. Wysocki
2017-10-16  6:00     ` Li, Aubrey
2017-10-17  0:01       ` Rafael J. Wysocki
2017-10-17  6:12         ` Li, Aubrey
2017-09-30  7:20 ` [RFC PATCH v2 7/8] cpuidle: introduce irq timing to make idle prediction Aubrey Li
2017-10-14  1:01   ` Rafael J. Wysocki
2017-10-16  6:03     ` Li, Aubrey
2017-09-30  7:20 ` [RFC PATCH v2 8/8] cpuidle: introduce run queue average idle " Aubrey Li
2017-10-14  1:02   ` Rafael J. Wysocki
2017-10-14  1:14 ` [RFC PATCH v2 0/8] Introduct cpu idle prediction functionality Rafael J. Wysocki
2017-10-16  7:44   ` Li, Aubrey
2017-10-17  0:07     ` Rafael J. Wysocki
2017-10-17  7:32       ` Li, Aubrey
2017-11-30  1:00 ` Li, Aubrey
2017-11-30  1:37   ` 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=1508135135.8087.17.camel@gmx.de \
    --to=efault@gmx.de \
    --cc=ak@linux.intel.com \
    --cc=aubrey.li@intel.com \
    --cc=aubrey.li@linux.intel.com \
    --cc=len.brown@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=peterz@infradead.org \
    --cc=rjw@rjwysocki.net \
    --cc=tglx@linutronix.de \
    --cc=tim.c.chen@linux.intel.com \
    /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.