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:	Thu, 12 Jul 2012 09:57:33 -0700
From:	John Stultz <john.stultz@...aro.org>
To:	Linus Walleij <linus.walleij@...aro.org>
CC:	Marc Zyngier <marc.zyngier@....com>,
	Deepak Saxena <dsaxena@...aro.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Walleij <linus.ml.walleij@...il.com>,
	Catalin Marinas <catalin.marinas@....com>,
	linux-kernel@...r.kernel.org, Arnd Bergmann <arnd@...db.de>,
	Will Deacon <will.deacon@....com>,
	Mike Turquette <mike.turquette@...aro.org>,
	Marc Zyngier <maz@...terjones.org>
Subject: Re: [PATCH 33/36] AArch64: Generic timers support

On 07/12/2012 03:56 AM, Linus Walleij wrote:
> On Thu, Jul 12, 2012 at 12:09 PM, Marc Zyngier <marc.zyngier@....com> wrote:
>
>> On Thu, 12 Jul 2012 02:18:42 +0200, Linus Walleij
>> <linus.ml.walleij@...il.com> wrote:
>>
>> Hi Linus,
>>
>>> I'm reviewing the only patch I really understand...
>>>
>>> 2012/7/6 Catalin Marinas <catalin.marinas@....com>:
>>>
>>>> +/* This isn't really used any more */
>>>> +#define CLOCK_TICK_RATE 1000
>>> Is it still necessary to even have it there?
>> It is used as part of the LATCH/TICK_* computation in
>> include/linux/jiffies.h. It seems that any value could do, actually, and it
>> only seem to be used in kernel/time/ntp.c. Any guidance on this much
>> appreciated.
>>
>> By the way, there is a very interesting comment about this in
>> arch/ia64/include/asm/timex.h.
> Hmmmm paging John Stultz, TGLX, Deepak Saxena who have been in
> this area...

Yea, its definitely crufty, but CLOCK_TICK_RATE is still important if 
you use the jiffies clocksource (usually in the case of hardware that 
does not support clocksources).

Basically its just trying to handle the cases where the time interval 
1sec/HZ  (for the various values of HZ) can not be accurately computed 
due to the granularity of the tick device.  In those cases we use 
CLOCK_TICK_RATE to figure out the granularity error and modify the 
length of a jiffie,  just slightly, so it matches the hardware.

Most architectures have some sort of copy-pasted version of i386's 
CLOCK_TICK_RATE (although I guess its possible some non-x86 systems 
might actually have an 8253 or similar timer) and since the move to 
GENERIC_TIME and clocksources, any incorrectly calculated error has very 
little effect on most hardware since its not used to track time.

So following ia64's method is probably better then copying the 8253's 
rate if you're not concerned about tick-granularity error.

thanks
-john


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