<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/kernel/time/timekeeping.c, branch v2.6.31-rc3</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/kernel/time/timekeeping.c?h=v2.6.31-rc3</id>
<link rel='self' href='https://git.amat.us/linux/atom/kernel/time/timekeeping.c?h=v2.6.31-rc3'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2009-06-11T06:01:14Z</updated>
<entry>
<title>Merge branch 'master' of git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6</title>
<updated>2009-06-11T06:01:14Z</updated>
<author>
<name>Paul Mundt</name>
<email>lethal@linux-sh.org</email>
</author>
<published>2009-06-11T06:01:14Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=cf9fe114e3b37e14fc8434d5abb192e35df551b1'/>
<id>urn:sha1:cf9fe114e3b37e14fc8434d5abb192e35df551b1</id>
<content type='text'>
</content>
</entry>
<entry>
<title>sched, timers: move calc_load() to scheduler</title>
<updated>2009-05-15T13:32:45Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2009-04-11T08:43:41Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=dce48a84adf1806676319f6f480e30a6daa012f9'/>
<id>urn:sha1:dce48a84adf1806676319f6f480e30a6daa012f9</id>
<content type='text'>
Dimitri Sivanich noticed that xtime_lock is held write locked across
calc_load() which iterates over all online CPUs. That can cause long
latencies for xtime_lock readers on large SMP systems. 

The load average calculation is an rough estimate anyway so there is
no real need to protect the readers vs. the update. It's not a problem
when the avenrun array is updated while a reader copies the values.

Instead of iterating over all online CPUs let the scheduler_tick code
update the number of active tasks shortly before the avenrun update
happens. The avenrun update itself is handled by the CPU which calls
do_timer().

[ Impact: reduce xtime_lock write locked section ]

Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Acked-by: Peter Zijlstra &lt;peterz@infradead.org&gt;
</content>
</entry>
<entry>
<title>timekeeping: create arch_gettimeoffset infrastructure</title>
<updated>2009-05-02T09:45:15Z</updated>
<author>
<name>john stultz</name>
<email>johnstul@us.ibm.com</email>
</author>
<published>2009-05-01T20:10:26Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7d27558c4138ac6b3684dea35c2f4379b940a7dd'/>
<id>urn:sha1:7d27558c4138ac6b3684dea35c2f4379b940a7dd</id>
<content type='text'>
Some arches don't supply their own clocksource. This is mainly the
case in architectures that get their inter-tick times by reading the
counter on their interval timer.  Since these timers wrap every tick,
they're not really useful as clocksources.  Wrapping them to act like
one is possible but not very efficient. So we provide a callout these
arches can implement for use with the jiffies clocksource to provide
finer then tick granular time.

[ Impact: ease the migration to generic time keeping ]

Signed-off-by: John Stultz &lt;johnstul@us.ibm.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
</content>
</entry>
<entry>
<title>clocksource: add enable() and disable() callbacks</title>
<updated>2009-04-21T20:41:47Z</updated>
<author>
<name>Magnus Damm</name>
<email>damm@igel.co.jp</email>
</author>
<published>2009-04-21T19:24:02Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=4614e6adafa2c5e6c3a9c245af2807fa7bc5117a'/>
<id>urn:sha1:4614e6adafa2c5e6c3a9c245af2807fa7bc5117a</id>
<content type='text'>
Add enable() and disable() callbacks for clocksources.

This allows us to put unused clocksources in power save mode.  The
functions clocksource_enable() and clocksource_disable() wrap the
callbacks and are inserted in the timekeeping code to enable before use
and disable after switching to a new clocksource.

Signed-off-by: Magnus Damm &lt;damm@igel.co.jp&gt;
Acked-by: John Stultz &lt;johnstul@us.ibm.com&gt;
Cc: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Linus Torvalds &lt;torvalds@linux-foundation.org&gt;
</content>
</entry>
<entry>
<title>sched_clock: prevent scd-&gt;clock from moving backwards, take #2</title>
<updated>2008-12-31T08:53:21Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2008-12-22T22:05:28Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=1c5745aa380efb6417b5681104b007c8612fb496'/>
<id>urn:sha1:1c5745aa380efb6417b5681104b007c8612fb496</id>
<content type='text'>
Redo:

  5b7dba4: sched_clock: prevent scd-&gt;clock from moving backwards

which had to be reverted due to s2ram hangs:

  ca7e716: Revert "sched_clock: prevent scd-&gt;clock from moving backwards"

... this time with resume restoring GTOD later in the sequence
taken into account as well.

The "timekeeping_suspended" flag is not very nice but we cannot call into
GTOD before it has been properly resumed and the scheduler will run very
early in the resume sequence.

Cc: &lt;stable@kernel.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>time: catch xtime_nsec underflows and fix them</title>
<updated>2008-12-04T07:43:02Z</updated>
<author>
<name>john stultz</name>
<email>johnstul@us.ibm.com</email>
</author>
<published>2008-12-02T02:34:41Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=6c9bacb41c10ba84ff68f238e234d96f35fb64f7'/>
<id>urn:sha1:6c9bacb41c10ba84ff68f238e234d96f35fb64f7</id>
<content type='text'>
Impact: fix time warp bug

Alex Shi, along with Yanmin Zhang have been noticing occasional time
inconsistencies recently. Through their great diagnosis, they found that
the xtime_nsec value used in update_wall_time was occasionally going
negative. After looking through the code for awhile, I realized we have
the possibility for an underflow when three conditions are met in
update_wall_time():

  1) We have accumulated a second's worth of nanoseconds, so we
     incremented xtime.tv_sec and appropriately decrement xtime_nsec.
     (This doesn't cause xtime_nsec to go negative, but it can cause it
      to be small).

  2) The remaining offset value is large, but just slightly less then
     cycle_interval.

  3) clocksource_adjust() is speeding up the clock, causing a
     corrective amount (compensating for the increase in the multiplier
     being multiplied against the unaccumulated offset value) to be
     subtracted from xtime_nsec.

This can cause xtime_nsec to underflow.

Unfortunately, since we notify the NTP subsystem via second_overflow()
whenever we accumulate a full second, and this effects the error
accumulation that has already occured, we cannot simply revert the
accumulated second from xtime nor move the second accumulation to after
the clocksource_adjust call without a change in behavior.

This leaves us with (at least) two options:

1) Simply return from clocksource_adjust() without making a change if we
   notice the adjustment would cause xtime_nsec to go negative.

This would work, but I'm concerned that if a large adjustment was needed
(due to the error being large), it may be possible to get stuck with an
ever increasing error that becomes too large to correct (since it may
always force xtime_nsec negative). This may just be paranoia on my part.

2) Catch xtime_nsec if it is negative, then add back the amount its
   negative to both xtime_nsec and the error.

This second method is consistent with how we've handled earlier rounding
issues, and also has the benefit that the error being added is always in
the oposite direction also always equal or smaller then the correction
being applied. So the risk of a corner case where things get out of
control is lessened.

This patch fixes bug 11970, as tested by Yanmin Zhang
http://bugzilla.kernel.org/show_bug.cgi?id=11970

Reported-by: alex.shi@intel.com
Signed-off-by: John Stultz &lt;johnstul@us.ibm.com&gt;
Acked-by: "Zhang, Yanmin" &lt;yanmin_zhang@linux.intel.com&gt;
Tested-by: "Zhang, Yanmin" &lt;yanmin_zhang@linux.intel.com&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>Merge branches 'timers/clocksource', 'timers/hrtimers', 'timers/nohz', 'timers/ntp', 'timers/posixtimers' and 'timers/debug' into v28-timers-for-linus</title>
<updated>2008-10-20T11:14:06Z</updated>
<author>
<name>Thomas Gleixner</name>
<email>tglx@linutronix.de</email>
</author>
<published>2008-10-20T11:14:06Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c465a76af658b443075d6efee1c3131257643020'/>
<id>urn:sha1:c465a76af658b443075d6efee1c3131257643020</id>
<content type='text'>
</content>
</entry>
<entry>
<title>timekeeping: fix rounding problem during clock update</title>
<updated>2008-09-24T15:33:13Z</updated>
<author>
<name>Roman Zippel</name>
<email>zippel@linux-m68k.org</email>
</author>
<published>2008-09-22T21:42:43Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=5cd1c9c5cf30d4b33df3d3f74d8142f278d536b7'/>
<id>urn:sha1:5cd1c9c5cf30d4b33df3d3f74d8142f278d536b7</id>
<content type='text'>
Due to a rounding problem during a clock update it's possible for readers
to observe the clock jumping back by 1nsec.  The following simplified
example demonstrates the problem:

cycle	xtime
0	0
1000	999999.6
2000	1999999.2
3000	2999998.8
...

1500 =	1499999.4
=	0.0 + 1499999.4
=	999999.6 + 499999.8

When reading the clock only the full nanosecond part is used, while
timekeeping internally keeps nanosecond fractions.  If the clock is now
updated at cycle 1500 here, a nanosecond is missing due to the truncation.

The simple fix is to round up the xtime value during the update, this also
changes the distance to the reference time, but the adjustment will
automatically take care that it stays under control.

Signed-off-by: Roman Zippel &lt;zippel@linux-m68k.org&gt;
Signed-off-by: John Stultz &lt;johnstul@us.ibm.com&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
</content>
</entry>
<entry>
<title>clocksource: introduce CLOCK_MONOTONIC_RAW</title>
<updated>2008-08-21T07:50:24Z</updated>
<author>
<name>John Stultz</name>
<email>johnstul@us.ibm.com</email>
</author>
<published>2008-08-20T23:37:30Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=2d42244ae71d6c7b0884b5664cf2eda30fb2ae68'/>
<id>urn:sha1:2d42244ae71d6c7b0884b5664cf2eda30fb2ae68</id>
<content type='text'>
In talking with Josip Loncaric, and his work on clock synchronization (see
btime.sf.net), he mentioned that for really close synchronization, it is
useful to have access to "hardware time", that is a notion of time that is
not in any way adjusted by the clock slewing done to keep close time sync.

Part of the issue is if we are using the kernel's ntp adjusted
representation of time in order to measure how we should correct time, we
can run into what Paul McKenney aptly described as "Painting a road using
the lines we're painting as the guide".

I had been thinking of a similar problem, and was trying to come up with a
way to give users access to a purely hardware based time representation
that avoided users having to know the underlying frequency and mask values
needed to deal with the wide variety of possible underlying hardware
counters.

My solution is to introduce CLOCK_MONOTONIC_RAW.  This exposes a
nanosecond based time value, that increments starting at bootup and has no
frequency adjustments made to it what so ever.

The time is accessed from userspace via the posix_clock_gettime() syscall,
passing CLOCK_MONOTONIC_RAW as the clock_id.

Signed-off-by: John Stultz &lt;johnstul@us.ibm.com&gt;
Signed-off-by: Roman Zippel &lt;zippel@linux-m68k.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
<entry>
<title>clocksource: introduce clocksource_forward_now()</title>
<updated>2008-08-21T07:50:24Z</updated>
<author>
<name>Roman Zippel</name>
<email>zippel@linux-m68k.org</email>
</author>
<published>2008-08-20T23:37:28Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=9a055117d3d9cb562f83f8d4cd88772761f4cab0'/>
<id>urn:sha1:9a055117d3d9cb562f83f8d4cd88772761f4cab0</id>
<content type='text'>
To keep the raw monotonic patch simple first introduce
clocksource_forward_now(), which takes care of the offset since the last
update_wall_time() call and adds it to the clock, so there is no need
anymore to deal with it explicitly at various places, which need to make
significant changes to the clock.

This is also gets rid of the timekeeping_suspend_nsecs, instead of
waiting until resume, the value is accumulated during suspend. In the end
there is only a single user of __get_nsec_offset() left, so I integrated
it back to getnstimeofday().

Signed-off-by: Roman Zippel &lt;zippel@linux-m68k.org&gt;
Signed-off-by: Andrew Morton &lt;akpm@linux-foundation.org&gt;
Signed-off-by: Ingo Molnar &lt;mingo@elte.hu&gt;
</content>
</entry>
</feed>
