Daniel Walker wrote:
+static void clocksource_settimeofday(struct clocksource *cs,
+ struct timespec *ts)
+{
+ u64 new_xsec;
+
+#ifdef CONFIG_PPC_ISERIES
+ if (firmware_has_feature(FW_FEATURE_ISERIES) && first_settimeofday) {
+ iSeries_tb_recal();
+ first_settimeofday = 0;
+ }
+#endif
+
+ /* Make userspace gettimeofday spin until we're done. */
+ ++vdso_data->tb_update_count;
+ smp_mb();
+
+ /* In case of a large backwards jump in time with NTP, we want the
+ * clock to be updated as soon as the PLL is again in lock.
+ */
+ last_rtc_update = xtime.tv_sec - 658;
+
+ new_xsec = xtime.tv_nsec;
+ if (new_xsec != 0) {
+ new_xsec *= XSEC_PER_SEC;
+ do_div(new_xsec, NSEC_PER_SEC);
+ }
+
+ new_xsec += (u64)xtime.tv_sec * XSEC_PER_SEC;
+
+ vdso_data->tz_minuteswest = sys_tz.tz_minuteswest;
+ vdso_data->tz_dsttime = sys_tz.tz_dsttime;
I'm not sure why these are copied *only* here. Shouldn't they be copied
only once, at init. time?
+
+ update_gtod(tb_last_jiffy, new_xsec, do_gtod.varp->tb_to_xs);
+}
It does look too large to run from interrupt context,
You mean if this would have been "included" into update_vsyscall()?
but it also looks
like it could get cleaned out more ..
Yeah, at least new_xsec calculation is duplicated in timer_recalc_offset()..
+void update_vsyscall(struct timespec *wall_time, struct clocksource *clock)
+{
+ timer_recalc_offset(tb_last_jiffy);
+ timer_check_rtc();
+}
Hmm .. This doesn't look like it's taking into account that the time has
changed ..
Why? By the time it gets called (form the timer softirq context)
tb_last_jiffy should've been incremented. Well, this won't happen wither in or
right after the timer interrupt... since timer has no IRQ on PowerPC -- it
signals "exception". Well, HRT works somehow anyway. :-)
Your time has effectively incremented by one jiffie .. The
vdso_data doesn't appear to be updated ..
Moreover, it will get called for settimeofday() as well which would seem
to double the overhead since your clocksource hook will get called beforehand.
WBR, Sergei
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
