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]

Message-Id: <200701061756.20470.zippel@linux-m68k.org>
Date:	Sat, 6 Jan 2007 17:56:20 +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

Hi,

On Tuesday 02 January 2007 21:50, john stultz wrote:

> > > It should be called every NTP_INTERVAL_FREQ times, but occasionally
> > > it's off
>
> Wait, so second_overflow should be called every NTP_INTERVAL_FREQ times
> (instead of every second)? Surely that's not right.

But it is, that's the reason the various adjustment values are divided by it, 
so they are applied to the next NTP_INTERVAL_FREQ times.

BTW I think NTP_INTERVAL_FREQ isn't the right name, CLOCK_UPDATE_FREQ would be 
a better name, currently ntp is the main user, but a clock can also be 
updated via other means (e.g. adjtimex or another clock).

> > > 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".)
>
> This would assume that clock->cycle_interval would *always* be the
> length of a full second and that isn't what the patch trying to do.
>
> Maybe could you explain this some more?

As I said this was the case for a value of one.
Anyway, to avoid these problems, I'd prefer to keep it at least at 2 or better 
at 4. This would still drastically reduce the time spent in the loop and we 
can revisit the issue later.

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/