From: Peter Zijlstra <peterz@infradead.org>
To: Len Brown <lenb@kernel.org>
Cc: Daniel Lezcano <daniel.lezcano@linaro.org>,
Linux PM list <linux-pm@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
axboe@kernel.dk, "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Ingo Molnar <mingo@kernel.org>,
preeti@linux.vnet.ibm.com,
Morten Rasmussen <Morten.Rasmussen@arm.com>,
mturquette@linaro.org,
Tuukka Tikkanen <tuukka.tikkanen@linaro.org>,
Nicolas Pitre <nicolas.pitre@linaro.org>,
Patch Tracking <patches@linaro.org>
Subject: Re: [RFD PATCH 01/10] sched: add io latency framework
Date: Thu, 30 Oct 2014 15:44:50 +0100 [thread overview]
Message-ID: <20141030144450.GG23531@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <CAJvTdKkF1Z9eUwjv4-idzCUTzD_MdEeZWOxkB+VmGoEcnJfk-A@mail.gmail.com>
On Mon, Oct 27, 2014 at 11:19:49PM -0400, Len Brown wrote:
> > There is a rb tree per cpu. Each time a task is blocked on an IO, it
> > is inserted into the tree. When the IO is complete and the task is
> > woken up, its avg latency is updated with the time spent to wait the
> > IO and it is removed from the tree. The next time, it will be inserted
> > into the tree again in case of io_schedule.
>
> Is there an assumption built-in here that the device interrupt is targeted
> at the same CPU as where the task is queued?
Yes, I pointed out that this is unlikely to be true during his
presentation in DUS.
My suggestion was to track interrupts per device and use the IRQ routing
to map them to CPUs.
The benchmarking of the approach was done on a UP (or rather, everything
affinity bound to cpu0) which did obviously not expose this particular
issue.
next prev parent reply other threads:[~2014-10-30 14:45 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 [this message]
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 ` [RFD PATCH 00/10] cpuidle: Predict the next events with the IO latencies Peter Zijlstra
2014-10-30 15:14 ` 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=20141030144450.GG23531@worktop.programming.kicks-ass.net \
--to=peterz@infradead.org \
--cc=Morten.Rasmussen@arm.com \
--cc=axboe@kernel.dk \
--cc=daniel.lezcano@linaro.org \
--cc=lenb@kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox