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]

Date:	Tue, 4 Mar 2008 20:42:17 +0100
From:	"Remy Bohmer" <linux@...mer.net>
To:	"Haavard Skinnemoen" <hskinnemoen@...el.com>
Cc:	akpm@...ux-foundation.org, LKML <linux-kernel@...r.kernel.org>,
	"David Brownell" <david-b@...bell.net>,
	"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

Hello Haavard,

Good work on improving this patch. I am very happy with the accurate
clocksource devices, I use the patches from David for quite some time
now.

But, I noticed this comment in the patch:

>  +/* 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.
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...

To prevent applications to start timers too fast after each other, it
is even useful to limit the granularity of these timers, and to get
them aligned so that they can be handled on just 1 interrupt. (Hmm,
this sounds like the behavior of a ticking kernel ;-))

This is the reason why I stopped using the High-resolution timer
framework on these cores. It just overloads the CPU too much when
several applications use independent timers that are not in sync with
each other. A ticking kernel is therefor more CPU-load friendly...

Kind Regards,

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