linux-kernel - Re: [PATCH] atmel_tc clocksource/clockevent code

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: <200803041247.50877.david-b@pacbell.net>
Date:	Tue, 4 Mar 2008 12:47:50 -0800
From:	David Brownell <david-b@...bell.net>
To:	"Remy Bohmer" <linux@...mer.net>
Cc:	"Haavard Skinnemoen" <hskinnemoen@...el.com>,
	akpm@...ux-foundation.org, LKML <linux-kernel@...r.kernel.org>,
	"David Brownell" <dbrownell@...rs.sourceforge.net>,
	"Nicolas Ferre" <nicolas.ferre@....atmel.com>,
	"Andrew Victor" <linux@...im.org.za>,
	"john stultz" <johnstul@...ibm.com>,
	"Thomas Gleixner" <tglx@...utronix.de>
Subject: Re: [PATCH] atmel_tc clocksource/clockevent code

On Tuesday 04 March 2008, Remy Bohmer wrote:
> >  +/* For now, we always use the 32K clock ... this optimizes for NO_HZ,
> >  + * because using one of the divided clocks would usually mean the
> >  + * tick rate can never be less than several dozen Hz (vs 0.5 Hz).
> >  + *
> >  + * A divided clock could be good for high resolution timers, since
> >  + * 30.5 usec resolution can seem "low".
> 
> I want to comment on that.
>
> I noticed that on rm9200 the timer interrupt handler itself can cost
> about 50us to more than 100usec in itself (measured through ETM
> trace), combined with a worst case interrupt latency of about 75us.

Could you elaborate on where that 50-100 usec gets spent?  Does
the same issue happpen with the $SUBJECT patch (if you tweak the
clocksource ratings to use its clockevents on rm9200)?

I'd not think the timer IRQ logic accounts for much of that time,
and the rest of the instruction cycles would seem to be either
in genirq or gentime.  Unless the issue is that accessing that
particular hardware is slow, with clockdomain crossing etc ...
or that AT91 has way too many handlers sitting on IRQ-1.

If it's a gentime or genirq issue, that's somewhat amenable to
fixing ... and it would also impact the $SUBJECT patch both on
other AT91 ARM9 cores and on the AVR32 AP7 cores.

> So, a higher resolution than 30usec is useless on these cores, and
> setting timers on a frequency that high will just choke the processor
> in only handling timers...

Should the min_delta_ns be increased in at91rm9200_time.c then?
Right now, as you probably recall, it's at the lowest value
needed for correctness:  a smidgeon over two ticks (~ 72 nsec).

- Dave

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