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: <1166035726.6425.1.camel@localhost.localdomain>
Date:	Wed, 13 Dec 2006 10:48:46 -0800
From:	john stultz <johnstul@...ibm.com>
To:	Ingo Molnar <mingo@...e.hu>
Cc:	Roman Zippel <zippel@...ux-m68k.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org
Subject: Re: [RFC] HZ free ntp

On Wed, 2006-12-13 at 10:51 +0100, Ingo Molnar wrote:
> * john stultz <johnstul@...ibm.com> wrote:
> 
> > On Wed, 2006-12-06 at 15:33 +0100, Roman Zippel wrote:
> > > On Wed, 6 Dec 2006, Ingo Molnar wrote:
> > > > i disagree with you and it's pretty low-impact anyway. There's still
> > > > quite many HZ/tick assumptions all around the time code (NTP being one
> > > > example), we'll deal with those via other patches.
> > >
> > > Why do you pick on the NTP code? That's actually one of the places where
> > > assumptions about HZ are largely gone. NTP state is updated incrementally
> > > and this won't change, but the update frequency can now be easily
> > > disconnected from HZ.
> >
> > Hey Roman,
> > 	Here's my rough first attempt at doing so. I'd not call it easy, but
> > maybe you have some suggestions for a simpler way?
> >
> > Basically INTERVAL_LENGTH_NSEC defines the NTP interval length that
> > the time code will use to accumulate with. In this patch I've pushed
> > it out to a full second, but it could be set via config
> > (NSEC_PER_SEC/HZ for regular systems, something larger for systems
> > using dynticks).
> 
> cool! I'll give this one a go in -rt, combined with the exponential
> second-overflow patch. (that one is now algorithmically safe, right?)

No, this one will replace the exponential accumulation patch. So we'll
accumulate on second intervals, which should be far enough apart that we
won't be spinning in that loop for long.

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/