lkml.org 
[lkml]   [2008]   [Oct]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH 2/4] timers: new framework for identifying cpu-pinned timers
From
Date
On Thu, 2008-10-16 at 17:18 +0530, Arun R Bharadwaj wrote:
> This patch creates the necessary framework for identifying cpu-pinned
> regular timers and hrtimers.
>
> For regular timers a new flag called TBASE_PINNED_FLAG is created.
> Since the last 3 bits of the tvec_base is guaranteed to be 0, and
> since the last bit is being used to indicate deferrable timers, I'm
> using the second last bit to indicate cpu-pinned regular timers.
> The implementation of functions to manage the TBASE_PINNED_FLAG is
> similar to those which manage the TBASE_DEFERRABLE_FLAG.
>
> For hrtimers, there is no clear interface to queue a hrtimer as a
> per-cpu hrtimer. But there are instances where, if an hrtimer is queued
> on a particular cpu, it expects to run on the same cpu.
> The hrtimer hrtick_timer is one such example.
>
> So, in this regard, I've created a new interface called
> hrtimer_start_pinned which can be used to queue cpu-pinned hrtimer.
> In the hrtimer structure, there is a variable called *state* which
> is used to indicate the state of a hrtimer - inactive, enqueued,
> callback function running and callback pending. Currently, since only
> 5 bits are being used in the state variable, I've used the 6th bit
> to represent the cpu-pinned state of the hrtimer
>
>
> Signed-off-by: Arun R Bharadwaj <arun@linux.vnet.ibm.com>

Thomas recently created HRTIMER_CB_IRQSAFE_PERCPU which serves this
purpose to close some cpu-hotplug timer races.

> @@ -97,6 +96,7 @@ enum hrtimer_cb_mode {
> #define HRTIMER_STATE_CALLBACK 0x02
> #define HRTIMER_STATE_PENDING 0x04
> #define HRTIMER_STATE_MIGRATE 0x08
> +#define HRTIMER_CPU_PINNED 0X16

Hehe, may I suggest 0x10 :-)



\
 
 \ /
  Last update: 2008-10-16 13:55    [from the cache]
©2003-2014 Jasper Spaans. Advertise on this site