linux-kernel - Re: [RFC] HZ free ntp

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:	Mon, 1 Jan 2007 19:29:28 +0100
From:	Roman Zippel <zippel@...ux-m68k.org>
To:	john stultz <johnstul@...ibm.com>
Cc:	Ingo Molnar <mingo@...e.hu>, Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org
Subject: Re: [RFC] HZ free ntp

On Wednesday 20 December 2006 02:54, john stultz wrote:

> And here would be the follow on patch (again *untested*) for
> CONFIG_NO_HZ slowing the time accumulation down to once per second.

Changing it to one creates a potential problem with calling second_overflow(). 
It should be called every NTP_INTERVAL_FREQ times, but occasionally it's off 
by one (when xtime is close to a full second and the tick length is different 
from 1sec). At a higher frequency that's not much of a problem, but at one it 
means second_overflow() is occasionally called twice a second or skipped for 
a second. Usually the error should be quite small, but sometimes it can be 
significant.
So in this case the loop in update_wall_time() should rather look like this:

	while (offset >= clock->cycle_interval) {
		...
		second_overflow();
		while (clock->xtime_nsec >= (u64)NSEC_PER_SEC << clock->shift) {
			clock->xtime_nsec -= (u64)NSEC_PER_SEC << clock->shift;
			xtime.tv_sec++;
		}
		...
	}

(Also note the change from "if" to "while".)

Another problem area is that the clock shift value might need adjustments, 
since when you reduce the update frequency, it also increases the error 
adjustment steps and thus influences the jitter. This is especially important 
if we want to synchronize the TSC on multiple cpu's.

bye, Roman
-
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/