Thread (1 message) 1 message, 1 author, 2009-04-02

Re: [v4 RFC PATCH 1/4] timers: Framework for identifying pinned timers

From: Arun R Bharadwaj <hidden>
Date: 2009-04-02 05:09:19

* Andi Kleen [off-list ref] [2009-04-01 13:41:46]:
On Wed, Apr 01, 2009 at 05:02:58PM +0530, Arun R Bharadwaj wrote:
quoted
* Arun R Bharadwaj [off-list ref] [2009-04-01 17:01:28]:

This patch creates a new framework for identifying cpu-pinned timers
and hrtimers.


This framework is needed because pinned timers are expected to fire on
the same CPU on which they are queued. So it is essential to identify
these and not migrate them, in case there are any.
How would that interact with add_timer_on()? You currently only
support the current CPU, don't you?

e.g. the new tip x86 machine check polling code relies on add_timer_on
staying on that CPU.
Pinned timers are directly related to add_timer_on().
So I assume that whatever timer is queued using add_timer_on() is
supposed to be a pinned timer.
Currently, we can stay on one CPU and still queue a pinned timer on
some other CPU. We can mark those timers as 'pinned' to that
particular CPU.

--arun
-Andi

-- 
ak@linux.intel.com -- Speaking for myself only.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help