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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:	Wed, 27 Aug 2008 11:24:19 +0200 (CEST)
From:	Thomas Gleixner <tglx@...utronix.de>
To:	Kevin Hao <haokexin@...il.com>
cc:	linux-kernel <linux-kernel@...r.kernel.org>, mingo@...hat.com
Subject: Re: [x86] apic timer tick interval is not so accurate in periodic
 mode

On Wed, 20 Aug 2008, Kevin Hao wrote:
> Hi all,
> 
> I found the apic timer tick interval is not so accurate when it works
> in periodic mode(CONFIG_HIGH_RES_TIMERS=N).
> But in one-shot mode(CONFIG_HIGH_RES_TIMERS=Y)  it works well.
> I tested it on a Dell390 pc. HZ is 250. Kernel version is 2.6.27-rc3.
> The following is the result:
> 
> In periodic mode:
> tick = 1, apic tick timer interval is 4020211
> tick = 1, apic tick timer interval is 4020233
> tick = 1, apic tick timer interval is 4020233
> tick = 1, apic tick timer interval is 4020199
> tick = 1, apic tick timer interval is 4020267
> tick = 1, apic tick timer interval is 4020218
> tick = 1, apic tick timer interval is 4020278
> tick = 1, apic tick timer interval is 4020173
> 
> 
> In one-shot mode:
> tick = 1, apic tick timer interval is 3999930
> tick = 1, apic tick timer interval is 4000035
> tick = 1, apic tick timer interval is 3999998
> tick = 1, apic tick timer interval is 4000005
> tick = 1, apic tick timer interval is 4000001
> tick = 1, apic tick timer interval is 4000009
> tick = 1, apic tick timer interval is 3999945
> tick = 1, apic tick timer interval is 4000024
> tick = 1, apic tick timer interval is 4000005
> 
> Why is there so big difference between these two mode?
> The attachment is my test program and config file.
> Any comments is appreciated .

The periodic mode uses a reload value which is calculated during
system startup and never touched again. At this point we do not have
the full timekeeping infrastructure working and your test code uses
the working infrastructure as reference.

In high resolution timer mode we reprogramm the local apic timer for
the next hrtimer instance which is enqueued. We calculate the delta
against the system time and then convert it to the local apic counter
value. 

But yes, it's surprising that the obvious calibration deviation of the
local apic timer, which results in longer times is not showing up in
one shot mode. It would be interesting to see the absolute time line
in terms of ktime_get() of those events versus the expiry value of the
hrtimer which drives the tick emulation in tick_sched_timer().

Thanks,

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