All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Daniel Lezcano <daniel.lezcano@linaro.org>
Cc: linux-pm@vger.kernel.org, linux-kernel@vger.kernel.org,
	axboe@kernel.dk, rafael.j.wysocki@intel.com, mingo@kernel.org,
	preeti@linux.vnet.ibm.com, Morten.Rasmussen@arm.com,
	mturquette@linaro.org, tuukka.tikkanen@linaro.org,
	nicolas.pitre@linaro.org, patches@linaro.org
Subject: Re: [RFD PATCH 00/10] cpuidle: Predict the next events with the IO latencies
Date: Thu, 30 Oct 2014 15:38:53 +0100	[thread overview]
Message-ID: <20141030143853.GF23531@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <1413986273-28522-1-git-send-email-daniel.lezcano@linaro.org>

On Wed, Oct 22, 2014 at 03:57:43PM +0200, Daniel Lezcano wrote:
> After discussing at the LPC2014 Dusseldorf, it appears the idea is
> good but the approach is wrong. The latency tracking must be done at
> the device level, per device and not in the task as what is doing this
> patchset.

end_page_writeback()->test_clear_page_writeback()->__bdi_writeout_inc()

Is the IO completion path that has a fair amount of statistics in, maybe
some of that is usable.


  parent reply	other threads:[~2014-10-30 14:38 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-22 13:57 [RFD PATCH 00/10] cpuidle: Predict the next events with the IO latencies Daniel Lezcano
2014-10-22 13:57 ` [RFD PATCH 01/10] sched: add io latency framework Daniel Lezcano
2014-10-28  3:19   ` Len Brown
2014-10-30 14:44     ` Peter Zijlstra
2014-10-22 13:57 ` [RFD PATCH 02/10] cpuidle: Checking the zero latency inside the governors does not make sense Daniel Lezcano
2014-10-28  3:11   ` Len Brown
2014-10-22 13:57 ` [RFD PATCH 03/10] sched: idle: cpudidle: Pass the latency req from idle.c Daniel Lezcano
2014-10-22 13:57 ` [RFD PATCH 04/10] sched: idle: Compute next timer event and pass it the cpuidle framework Daniel Lezcano
2014-10-22 13:57 ` [RFD PATCH 05/10] cpuidle: Remove unused headers for tick Daniel Lezcano
2014-10-22 13:57 ` [RFD PATCH 06/10] sched: idle: Add io latency information for the next event Daniel Lezcano
2014-10-22 13:57 ` [RFD PATCH 07/10] cpuidle: Add a simple select governor Daniel Lezcano
2014-10-22 13:57 ` [RFD PATCH 08/10] cpuidle: select: hack - increase rating to have this governor as default Daniel Lezcano
2014-10-22 13:57 ` [RFD PATCH 09/10] cpuidle: sysfs: Add per cpu idle state prediction statistics Daniel Lezcano
2014-10-22 13:57 ` [RFD PATCH 10/10] sched: io_latency: Tracking via buckets Daniel Lezcano
2014-10-30 14:46   ` Peter Zijlstra
2014-10-30 15:07     ` Nicolas Pitre
2014-10-30 14:38 ` Peter Zijlstra [this message]
2014-10-30 15:14   ` [RFD PATCH 00/10] cpuidle: Predict the next events with the IO latencies Nicolas Pitre

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=20141030143853.GF23531@worktop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=Morten.Rasmussen@arm.com \
    --cc=axboe@kernel.dk \
    --cc=daniel.lezcano@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=mturquette@linaro.org \
    --cc=nicolas.pitre@linaro.org \
    --cc=patches@linaro.org \
    --cc=preeti@linux.vnet.ibm.com \
    --cc=rafael.j.wysocki@intel.com \
    --cc=tuukka.tikkanen@linaro.org \
    /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.