linux-kernel - Re: [RFC] exponential update_wall

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: <Pine.LNX.4.64.0609280128330.6761@scrub.home>
Date:	Thu, 28 Sep 2006 01:40:48 +0200 (CEST)
From:	Roman Zippel <zippel@...ux-m68k.org>
To:	john stultz <johnstul@...ibm.com>
cc:	lkml <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...l.org>
Subject: Re: [RFC] exponential update_wall_time

Hi,

On Wed, 27 Sep 2006, john stultz wrote:

> > This is the wrong approach, second_overflow() should be called every HZ
> > increment steps and your patch breaks this.
> 
> First, forgive me, since I've got a bit of a head cold, so I'm even
> slower then usual. I just don't see how this patch changes the behavior.
> Every second we will call second_overflow. But in the case where we
> skipped 100 ticks, we don't loop 100 times. Could you explain this a bit
> more?

second_overflow() changes the tick length, but the new tick length is now 
applied to varying number of ticks with your patch, which is bad for 
correct timekeeping.

> > There are other approaches oo accommodate dyntick. 
> > 1. You could make HZ in ntp_update_frequency() dynamic and thus reduce the 
> > frequency with which update_wall_time() needs to be called (Note that 
> > other clock variables like cycle_interval have to be adjusted as well). 
> 
> I'm not sure how this is functionally different from what this patch
> does.
> 
> 
> > 2. If dynticks stops the timer interrupt for a long time, it could 
> > precalculate a few things, e.g. it could complete the second and then 
> > advance the time in full seconds.
> 
> Not following this one at all.

You have to keep in mind that ntp time is basically advanced in 1 second 
steps (or HZ ticks or freq cycles to be precise) and you have to keep that 
property. You can slice that second however you like, but it still has to 
add up to 1 second. Right now we slice it into HZ steps, but this can be 
rather easily changed now.

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/