Skip to content

K
kernel_linux

OpenHarmony / kernel_linux
上一次同步 4 年多

通知 15
Star 8
Fork 2
K
kernel_linux
切换分支/标签
  1. 05 10月, 2009 1 次提交
    • J
      time: Implement logarithmic time accumulation · a092ff0f
      由 john stultz 提交于 
      Accumulating one tick at a time works well unless we're using NOHZ.
Then it can be an issue, since we may have to run through the loop
a few thousand times, which can increase timer interrupt caused
latency.

The current solution was to accumulate in half-second intervals
with NOHZ. This kept the number of loops down, however it did
slightly change how we make NTP adjustments. While not an issue
with NTPd users, as NTPd makes adjustments over a longer period of
time, other adjtimex() users have noticed the half-second
granularity with which we can apply frequency changes to the clock.

For instance, if a application tries to apply a 100ppm frequency
correction for 20ms to correct a 2us offset, with NOHZ they either
get no correction, or a 50us correction.

Now, there will always be some granularity error for applying
frequency corrections. However with users sensitive to this error
have seen a 50-500x increase with NOHZ compared to running without
NOHZ.

So I figured I'd try another approach then just simply increasing
the interval. My approach is to consume the time interval
logarithmically. This reduces the number of times through the loop
needed keeping latency down, while still preserving the original
granularity error for adjtimex() changes.

Further, this change allows us to remove the xtime_cache code
(patch to follow), as xtime is always within one tick of the
current time, instead of the half-second updates it saw before.

An earlier version of this patch has been shipping to x86 users in
the RedHat MRG releases for awhile without issue, but I've reworked
this version to be even more careful about avoiding possible
overflows if the shift value gets too large.
Signed-off-by: NJohn Stultz <johnstul@us.ibm.com>
Acked-by: NThomas Gleixner <tglx@linutronix.de>
Reviewed-by: NJohn Kacur <jkacur@redhat.com>
Cc: Clark Williams <williams@redhat.com>
Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
LKML-Reference: <1254525473.7741.88.camel@localhost.localdomain>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a092ff0f
  3. 28 8月, 2009 1 次提交
    • J
      ntp: Provide compability defines (You say MOD_NANO, I say ADJ_NANO) · c95b4502
      由 john stultz 提交于 
      MOD_NANO, ADJ_NANO, MOD_NANO, ADJ_NANO!
Lets call the whole thing off!
But oh! If we call the whole thing off,
Then we must part.
And oh! If we ever part,
Then that might break my heart^H^H^H^Hclock!
So, if you like MOD_NANO and I like ADJ_NANO,
I'll include MOD_NANO and give up ADJ_NANO (not really!).
For we know we need each other,
So we better call the calling off off.
Let's call the whole thing off!

The tumultuous NTP and Linux relationship has hit another snag: Ends
up NTPd still uses the "xntp 3.4 compatability names" and when the
STA_NANO value was added (along with ADJ_NANO), NTPd expected MOD_NANO
to be added and has apparently hit some build errors.

Report to ntp hackers:
https://lists.ntp.org/pipermail/hackers/2009-August/004455.html

Related Bugs:
https://support.ntp.org/bugs/show_bug.cgi?id=1219
https://bugzilla.redhat.com/show_bug.cgi?id=505566

So in an effort to make peace, here's a patch to help get things
building again. I also have updated the comment to make sure folks
don't think the MOD_* values are just legacy constants.

Of course, NTPd really uses the glibc-headers, so those will need to
be similarly updated before things are working again (the RH bug above
should probably cover that).

Thanks to Michael Tatarinov and Hal Murray for finding and reporting
the issue!
Signed-off-by: NJohn Stultz <johnstul@us.ibm.com>
Cc: Miroslav Lichvar <mlichvar@redhat.com>
Cc: hmurray@megapathdsl.net
Cc: Ulrich Drepper <drepper@redhat.com>
Cc: Michael Tatarinov <kukabu@gmail.com>
LKML-Reference: <1251417882.7905.42.camel@localhost.localdomain>
Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      c95b4502
  5. 17 6月, 2009 1 次提交
    • A
      time: move PIT_TICK_RATE to linux/timex.h · 08604bd9
      由 Arnd Bergmann 提交于 
      PIT_TICK_RATE is currently defined in four architectures, but in three
different places.  While linux/timex.h is not the perfect place for it, it
is still a reasonable replacement for those drivers that traditionally use
asm/timex.h to get CLOCK_TICK_RATE and expect it to be the PIT frequency.

Note that for Alpha, the actual value changed from 1193182UL to 1193180UL.
 This is unlikely to make a difference, and probably can only improve
accuracy.  There was a discussion on the correct value of CLOCK_TICK_RATE
a few years ago, after which every existing instance was getting changed
to 1193182.  According to the specification, it should be
1193181.818181...
Signed-off-by: NArnd Bergmann <arnd@arndb.de>
Cc: Richard Henderson <rth@twiddle.net>
Cc: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Ralf Baechle <ralf@linux-mips.org>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Len Brown <lenb@kernel.org>
Cc: john stultz <johnstul@us.ibm.com>
Cc: Dmitry Torokhov <dtor@mail.ru>
Cc: Takashi Iwai <tiwai@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      08604bd9
  7. 12 5月, 2009 1 次提交
  9. 06 5月, 2009 1 次提交
    • J
      ntp: adjust SHIFT_PLL to improve NTP convergence · 22cfbbfd
      由 john stultz 提交于 
      The conversion to the ntpv4 reference model
f1992393 ("ntp: convert to the NTP4
reference model") in 2.6.19 added nanosecond resolution the adjtimex
interface, but also changed the "stiffness" of the frequency adjustments,
causing NTP convergence time to greatly increase.

SHIFT_PLL, which reduces the stiffness of the freq adjustments, was
designed to be inversely linked to HZ, and the reference value of 4 was
designed for Unix systems using HZ=100.  However Linux's clock steering
code mostly independent of HZ.

So this patch reduces the SHIFT_PLL value from 4 to 2, which causes NTPd
behavior to match kernels prior to 2.6.19, greatly reducing convergence
times, and improving close synchronization through environmental thermal
changes.

The patch also changes some l's to L's in nearby code to avoid misreading
50l as 501.

[ Impact: tweak NTP algorithm for faster convergence ]
Signed-off-by: NJohn Stultz <johnstul@us.ibm.com>
Acked-by: NRik van Riel <riel@redhat.com>
Cc: zippel@linux-m68k.org
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
LKML-Reference: <200905051956.n45JuVo9025575@imap1.linux-foundation.org>
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      22cfbbfd
  11. 26 2月, 2009 1 次提交
    • I
      time: ntp: make 64-bit constants more robust · 2b9d1496
      由 Ingo Molnar 提交于 
      Impact: cleanup, no functionality changed

 - make PPM_SCALE an explicit s64 constant, to
   remove (s64) casts from usage sites.

kernel/time/ntp.o:

   text	   data	    bss	    dec	    hex	filename
   2536	    114	    136	   2786	    ae2	ntp.o.before
   2536	    114	    136	   2786	    ae2	ntp.o.after

md5:
   40a7728d1188aa18e83e21a81fa7b150  ntp.o.before.asm
   40a7728d1188aa18e83e21a81fa7b150  ntp.o.after.asm
Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2b9d1496
  13. 13 12月, 2008 1 次提交
  15. 24 9月, 2008 1 次提交
  17. 22 8月, 2008 1 次提交
  19. 01 5月, 2008 7 次提交
  21. 09 3月, 2008 1 次提交
  23. 10 2月, 2008 1 次提交
  25. 07 2月, 2008 1 次提交
    • A
      read_current_timer() cleanups · 941e492b
      由 Andrew Morton 提交于 
      - All implementations can be __devinit

- The function prototypes were in asm/timex.h but they all must be the same,
  so create a single declaration in linux/timex.h.

- uninline the sparc64 version to match the other architectures

- Don't bother #defining ARCH_HAS_READ_CURRENT_TIMER to a particular value.

[ezk@cs.sunysb.edu: fix build]
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Haavard Skinnemoen <hskinnemoen@atmel.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: Ingo Molnar <mingo@elte.hu>
Cc: Andi Kleen <ak@suse.de>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      941e492b
  27. 27 11月, 2007 1 次提交
  29. 21 7月, 2007 1 次提交
  31. 17 2月, 2007 1 次提交
  33. 12 2月, 2007 1 次提交
  35. 06 10月, 2006 1 次提交
  37. 01 10月, 2006 9 次提交
  39. 13 9月, 2006 1 次提交
  41. 27 6月, 2006 2 次提交
  43. 26 4月, 2006 1 次提交
  45. 27 3月, 2006 1 次提交
  47. 26 3月, 2006 1 次提交
  49. 18 2月, 2006 1 次提交
    • P
      [PATCH] Provide an interface for getting the current tick length · 726c14bf
      由 Paul Mackerras 提交于 
      This provides an interface for arch code to find out how many
nanoseconds are going to be added on to xtime by the next call to
do_timer.  The value returned is a fixed-point number in 52.12 format
in nanoseconds.  The reason for this format is that it gives the
full precision that the timekeeping code is using internally.

The motivation for this is to fix a problem that has arisen on 32-bit
powerpc in that the value returned by do_gettimeofday drifts apart
from xtime if NTP is being used.  PowerPC is now using a lockless
do_gettimeofday based on reading the timebase register and performing
some simple arithmetic.  (This method of getting the time is also
exported to userspace via the VDSO.)  However, the factor and offset
it uses were calculated based on the nominal tick length and weren't
being adjusted when NTP varied the tick length.

Note that 64-bit powerpc has had the lockless do_gettimeofday for a
long time now.  It also had an extremely hairy routine that got called
from the 32-bit compat routine for adjtimex, which adjusted the
factor and offset according to what it thought the timekeeping code
was going to do.  Not only was this only called if a 32-bit task did
adjtimex (i.e. not if a 64-bit task did adjtimex), it was also
duplicating computations from kernel/timer.c and it wasn't clear that
it was (still) correct.

The simple solution is to ask the timekeeping code how long the
current jiffy will be on each timer interrupt, after calling
do_timer.  If this jiffy will be a different length from the last one,
we then need to compute new values for the factor and offset used in
the lockless do_gettimeofday.  In this way we can keep xtime and
do_gettimeofday in sync, even when NTP is varying the tick length.

Note that when adjtimex varies the tick length, it almost always
introduces the variation from the next tick on.  The only case I could
see where adjtimex would vary the length of the current tick is when
an old-style adjtime adjustment is being cancelled.  (It's not clear
to me why the adjustment has to be cancelled immediately rather than
from the next tick on.)  Thus I don't see any real need for a hook in
adjtimex; the rare case of an old-style adjustment being cancelled can
be fixed up at the next tick.
Signed-off-by: NPaul Mackerras <paulus@samba.org>
Acked-by: Njohn stultz <johnstul@us.ibm.com>
Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      726c14bf