linux-toradex.git/kernel/time, branch v2.6.25-rc2

ntp: correct inconsistent interval/tick_length usage

2008-02-10T09:48:03+00:00

clocksource initialization and error accumulation.  This corrects a 280ppm
drift seen on some systems using acpi_pm, and affects other clocksources as
well (likely to a lesser degree).

Signed-off-by: John Stultz 
Cc: Roman Zippel 
Cc: Steven Rostedt 
Signed-off-by: Andrew Morton 
Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner

time: fix typo in comments

2008-02-08T17:22:29+00:00

Fix typo in comments.

BTW: I have to fix coding style in arch/ia64/kernel/time.c also, otherwise
checkpatch.pl will be complaining.

Signed-off-by: Li Zefan 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: john stultz 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

timekeeping: rename timekeeping_is_continuous to timekeeping_valid_for_hres

2008-02-08T17:22:29+00:00

Function timekeeping_is_continuous() no longer checks flag
CLOCK_IS_CONTINUOUS, and it checks CLOCK_SOURCE_VALID_FOR_HRES now.  So rename
the function accordingly.

Signed-off-by: Li Zefan 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: john stultz 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

clockevent: simplify list operations

2008-02-08T17:22:29+00:00

list_for_each_safe() suffices here.

Signed-off-by: Li Zefan 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: john stultz 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

clocksource: remove redundant code

2008-02-08T17:22:29+00:00

Flag CLOCK_SOURCE_WATCHDOG is cleared twice.  Note clocksource_change_rating()
won't do anyting with the cs flag.

Signed-off-by: Li Zefan 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: john stultz 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

time: fix sysfs_show_{available,current}_clocksources() buffer overflow problem

2008-02-06T18:41:03+00:00

I found that there is a buffer overflow problem in the following code.

Version:	2.6.24-rc2,
File:		kernel/time/clocksource.c:417-432
--------------------------------------------------------------------
static ssize_t
sysfs_show_available_clocksources(struct sys_device *dev, char *buf)
{
	struct clocksource *src;
	char *curr = buf;

	spin_lock_irq(&clocksource_lock);
	list_for_each_entry(src, &clocksource_list, list) {
		curr += sprintf(curr, "%s ", src->name);
	}
	spin_unlock_irq(&clocksource_lock);

	curr += sprintf(curr, "\n");

	return curr - buf;
}
-----------------------------------------------------------------------

sysfs_show_current_clocksources() also has the same problem though in practice
the size of current clocksource's name won't exceed PAGE_SIZE.

I fix the bug by using snprintf according to the specification of the kernel
(Version:2.6.24-rc2,File:Documentation/filesystems/sysfs.txt)

Fix sysfs_show_available_clocksources() and sysfs_show_current_clocksources()
buffer overflow problem with snprintf().

Signed-off-by: Miao Xie 
Cc: WANG Cong 
Cc: Thomas Gleixner 
Cc: john stultz 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

tick-sched: add more debug information

2008-02-01T16:45:14+00:00

To allow better diagnosis of tick-sched related, especially NOHZ
related problems, we need to know when the last wakeup via an irq
happened and when the CPU left the idle state.

Add two fields (idle_waketime, idle_exittime) to the tick_sched
structure and add them to the timer_list output.

Signed-off-by: Thomas Gleixner 
Signed-off-by: Ingo Molnar

timekeeping: update xtime_cache when time(zone) changes

2008-02-01T16:45:13+00:00

xtime_cache needs to be updated whenever xtime and or wall_to_monotic
are changed. Otherwise users of xtime_cache might see a stale (and in
the case of timezone changes utterly wrong) value until the next
update happens.

Fixup the obvious places, which miss this update.

Signed-off-by: Thomas Gleixner 
Acked-by: John Stultz 
Tested-by: Dhaval Giani 
Signed-off-by: Ingo Molnar

time: track accurate idle time with tick_sched.idle_sleeptime

2008-01-30T12:30:04+00:00

Current idle time in kstat is based on jiffies and is coarse grained.
tick_sched.idle_sleeptime is making some attempt to keep track of idle time
in a fine grained manner.  But, it is not handling the time spent in
interrupts fully.

Make tick_sched.idle_sleeptime accurate with respect to time spent on
handling interrupts and also add tick_sched.idle_lastupdate, which keeps
track of last time when idle_sleeptime was updated.

This statistics will be crucial for cpufreq-ondemand governor, which can
shed some conservative gaurd band that is uses today while setting the
frequency.  The ondemand changes that uses the exact idle time is coming
soon.

Signed-off-by: Venkatesh Pallipadi 
Signed-off-by: Andrew Morton 
Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner

NTP: correct inconsistent ntp interval/tick_length usage

2008-01-30T12:30:03+00:00

I recently noticed on one of my boxes that when synched with an NTP
server, the drift value reported for the system was ~283ppm. While in
some cases, clock hardware can be that bad, it struck me as unusual as
the system was using the acpi_pm clocksource, which is one of the more
trustworthy and accurate clocksources on x86 hardware.

I brought up another system and let it sync to the same NTP server, and
I noticed a similar 280some ppm drift.

In looking at the code, I found that the acpi_pm's constant frequency
was being computed correctly at boot-up, however once the system was up,
even without the ntp daemon running, the clocksource's frequency was
being modified by the clocksource_adjust() function.

Digging deeper, I realized that in the code that keeps track of how much
the clocksource is skewing from the ntp desired time, we were using
different lengths to establish how long an time interval was.

The clocksource was being setup with the following interval:
	NTP_INTERVAL_LENGTH = NSEC_PER_SEC/NTP_INTERVAL_FREQ

While the ntp code was using the tick_length_base value:
	tick_length_base ~= (tick_usec * NSEC_PER_USEC * USER_HZ)
					/NTP_INTERVAL_FREQ

The subtle difference is:
	(tick_usec * NSEC_PER_USEC * USER_HZ) != NSEC_PER_SEC

This difference in calculation was causing the clocksource correction
code to apply a correction factor to the clocksource so the two
intervals were the same, however this results in the actual frequency of
the clocksource to be made incorrect. I believe this difference would
affect all clocksources, although to differing degrees depending on the
clocksource resolution.

The issue was introduced when my HZ free ntp patch landed in 2.6.21-rc1,
so my apologies for the mistake, and for not noticing it until now.

The following patch, corrects the clocksource's initialization code so
it uses the same interval length as the code in ntp.c. After applying
this patch, the drift value for the same system went from ~283ppm to
only 2.635ppm.

I believe this patch to be good, however it does affect all arches and
I've only tested on x86, so some caution is advised. I do think it would
be a likely candidate for a stable 2.6.24.x release.

Any thoughts or feedback would be appreciated.

Signed-off-by: John Stultz 
Signed-off-by: Ingo Molnar 
Signed-off-by: Thomas Gleixner