linux-kernel - Re: [RFC PATCH 2/4] timers: new framework for identifying cpu-pinned timers

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Thu, 16 Oct 2008 16:03:37 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
cc:	arun@...ux.vnet.ibm.com, linux-kernel@...r.kernel.org,
	linux-pm@...ts.linux-foundation.org, ego@...ibm.com, mingo@...e.hu,
	andi@...stfloor.org, venkatesh.pallipadi@...el.com,
	vatsa@...ux.vnet.ibm.com, arjan@...radead.org
Subject: Re: [RFC PATCH 2/4] timers: new framework for identifying cpu-pinned
 timers

On Thu, 16 Oct 2008, Peter Zijlstra wrote:
> 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@...ux.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 :-)

Well, either way. Adding this to the state is horrible. The state
tracking is complex enough already, we do not need some extra non
state information for this.

Thanks,

	tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/