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: <20130121211218.GX23505@n2100.arm.linux.org.uk>
Date:	Mon, 21 Jan 2013 21:12:18 +0000
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	John Stultz <john.stultz@...aro.org>
Cc:	Arnd Bergmann <arnd@...db.de>, Matt Sealey <matt@...esi-usa.com>,
	Linux ARM Kernel ML <linux-arm-kernel@...ts.infradead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Ingo Molnar <mingo@...hat.com>, Ben Dooks <ben@...tec.co.uk>
Subject: Re: One of these things (CONFIG_HZ) is not like the others..

On Mon, Jan 21, 2013 at 01:00:15PM -0800, John Stultz wrote:
> So if you can not get actual timer ticks any faster then 200 HZ on that  
> hardware, setting HZ higher could cause some jiffies related timer  
> trouble

Err, no John.  It's the other way around - especially on some platforms
which are incapable of being converted to the clock source support.

EBSA110 has _one_ counter.  It counts down at a certain rate, and when
it rolls over from 0 to FFFF, it produces an interrupt and continues
counting down from FFFF.

To produce anything close to a reasonable regular tick rate from that,
the only way to do it is - with interrupts disabled - read the current
value to find out how far the timer has rolled over, and set it so that
the next event will expire as close as possible to the desired HZ rate.

So, none of the clcokevent stuff can be used; and we rely _purely_ on
counting interrupts in jiffy based increments to provide any reference
of time.

Moreover, because the counter is only 16-bit, and it's clocked from
something around 7MHz, well, maths will tell you why 200Hz had to be
chosen rather than 100Hz.
--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ