)]}'
{
  "commit": "a092ff0f90cae22b2ac8028ecd2c6f6c1a9e4601",
  "tree": "79ec451d0bcdf6c08e0bc210b4beed694fbbf4a9",
  "parents": [
    "8a0382f6fceaf0c6479e582e1054f36333ea3d24"
  ],
  "author": {
    "name": "john stultz",
    "email": "johnstul@us.ibm.com",
    "time": "Fri Oct 02 16:17:53 2009 -0700"
  },
  "committer": {
    "name": "Ingo Molnar",
    "email": "mingo@elte.hu",
    "time": "Mon Oct 05 13:51:48 2009 +0200"
  },
  "message": "time: Implement logarithmic time accumulation\n\nAccumulating one tick at a time works well unless we\u0027re using NOHZ.\nThen it can be an issue, since we may have to run through the loop\na few thousand times, which can increase timer interrupt caused\nlatency.\n\nThe current solution was to accumulate in half-second intervals\nwith NOHZ. This kept the number of loops down, however it did\nslightly change how we make NTP adjustments. While not an issue\nwith NTPd users, as NTPd makes adjustments over a longer period of\ntime, other adjtimex() users have noticed the half-second\ngranularity with which we can apply frequency changes to the clock.\n\nFor instance, if a application tries to apply a 100ppm frequency\ncorrection for 20ms to correct a 2us offset, with NOHZ they either\nget no correction, or a 50us correction.\n\nNow, there will always be some granularity error for applying\nfrequency corrections. However with users sensitive to this error\nhave seen a 50-500x increase with NOHZ compared to running without\nNOHZ.\n\nSo I figured I\u0027d try another approach then just simply increasing\nthe interval. My approach is to consume the time interval\nlogarithmically. This reduces the number of times through the loop\nneeded keeping latency down, while still preserving the original\ngranularity error for adjtimex() changes.\n\nFurther, this change allows us to remove the xtime_cache code\n(patch to follow), as xtime is always within one tick of the\ncurrent time, instead of the half-second updates it saw before.\n\nAn earlier version of this patch has been shipping to x86 users in\nthe RedHat MRG releases for awhile without issue, but I\u0027ve reworked\nthis version to be even more careful about avoiding possible\noverflows if the shift value gets too large.\n\nSigned-off-by: John Stultz \u003cjohnstul@us.ibm.com\u003e\nAcked-by: Thomas Gleixner \u003ctglx@linutronix.de\u003e\nReviewed-by: John Kacur \u003cjkacur@redhat.com\u003e\nCc: Clark Williams \u003cwilliams@redhat.com\u003e\nCc: Martin Schwidefsky \u003cschwidefsky@de.ibm.com\u003e\nCc: Andrew Morton \u003cakpm@linux-foundation.org\u003e\nLKML-Reference: \u003c1254525473.7741.88.camel@localhost.localdomain\u003e\nSigned-off-by: Ingo Molnar \u003cmingo@elte.hu\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "e6967d10d9e5ea39f77efecca64c59beb9d009d5",
      "old_mode": 33188,
      "old_path": "include/linux/timex.h",
      "new_id": "0c0ef7d4db7ce3f7ab3701b3b450d18b3b56133a",
      "new_mode": 33188,
      "new_path": "include/linux/timex.h"
    },
    {
      "type": "modify",
      "old_id": "fb0f46fa1ecd0fc09b656e2759ff990372faacb3",
      "old_mode": 33188,
      "old_path": "kernel/time/timekeeping.c",
      "new_id": "5fdd78e0858aa032e05e6c327b50988658adeb8c",
      "new_mode": 33188,
      "new_path": "kernel/time/timekeeping.c"
    }
  ]
}