linux-kernel - Re: [PATCH v2 1/3] drivers: clocksource: configure event stream for ARM arch timer

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130723103333.GB30942@mudshark.cambridge.arm.com>
Date:	Tue, 23 Jul 2013 11:33:33 +0100
From:	Will Deacon <will.deacon@....com>
To:	Catalin Marinas <catalin.marinas@....com>
Cc:	Sudeep KarkadaNagesha <Sudeep.KarkadaNagesha@....com>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Mark Rutland <Mark.Rutland@....com>,
	Lorenzo Pieralisi <Lorenzo.Pieralisi@....com>,
	Russell King <linux@....linux.org.uk>,
	Mathieu Poirier <mathieu.poirier@...aro.org>
Subject: Re: [PATCH v2 1/3] drivers: clocksource: configure event stream for
 ARM arch timer

On Tue, Jul 23, 2013 at 11:23:34AM +0100, Catalin Marinas wrote:
> On Mon, Jul 22, 2013 at 12:21:20PM +0100, Sudeep KarkadaNagesha wrote:
> > From: Will Deacon <will.deacon@....com>
> > 
> > The ARM architected timer can generate events (used for waking up
> > CPUs executing the wfe instruction) at a frequency represented as a
> > power-of-2 divisor of the clock rate.
> > 
> > This patch configures the event stream, aiming for a period of 100us
> > between events. This can be used to implement wfe-based timeouts for
> > userspace locking implementations.
> ...
> > --- a/include/clocksource/arm_arch_timer.h
> > +++ b/include/clocksource/arm_arch_timer.h
> > @@ -29,6 +29,8 @@
> >  #define ARCH_TIMER_PHYS_ACCESS		0
> >  #define ARCH_TIMER_VIRT_ACCESS		1
> >  
> > +#define ARCH_TIMER_EVT_STREAM_FREQ	10000	/* 100us */
> 
> BTW, if user-space starts using this, it will become an ABI. Is this the
> right frequency?

It doesn't quite become ABI; not all platforms will use the architected
timers and not all timers can support an arbitrary frequency. The best we
can do is calculate something as close to the target value as possible.

I spoke to both tools developers and some HSA driver guys about the frequency,
and this is what ended up being suggested.

> In addition, do we want to expose this via hwcap? Something like
> HWCAP_EVSTR100US?

Hmm, maybe, but we don't want people to try and use this for any accurate
time measurements, so I wouldn't include the period.

Will
--
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/