Re: [RFC][PATCH] new timeofday core subsystem (v. A2)

From: Tim Bird
Date: Tue Feb 01 2005 - 17:08:21 EST


Minor spelling fix, and a question.

john stultz wrote:
> linux-2.6.11-rc2_timeofday-core_A2.patch
> ========================================
> diff -Nru a/drivers/Makefile b/drivers/Makefile
> --- a/drivers/Makefile 2005-01-24 13:30:06 -08:00
> +++ b/drivers/Makefile 2005-01-24 13:30:06 -08:00
...

> + * all systems. It has the same course resolution as
should be "coarse"

Do you replace get_cmos_time() - it doesn't look like it.

You use it in your patch here...

> diff -Nru a/arch/i386/kernel/time.c b/arch/i386/kernel/time.c
> --- a/arch/i386/kernel/time.c 2005-01-24 13:33:59 -08:00
> +++ b/arch/i386/kernel/time.c 2005-01-24 13:33:59 -08:00
...

> +/* arch specific timeofday hooks */
> +nsec_t read_persistent_clock(void)
> +{
> + return (nsec_t)get_cmos_time() * NSEC_PER_SEC;
> +}
> +

I didn't scan for all uses of read_persistent_clock, but
in my experience get_cmos_time() has a latency of up to
1 second on x86 because it synchronizes with the rollover
of the RTC seconds.

This comment in timeofday.c:timeofday_suspend_hook
worries me:

> + /* First off, save suspend start time
> + * then quickly read the time source.
> + * These two calls hopefully occur quickly
> + * because the difference will accumulate as
> + * time drift on resume.
> + */
> + suspend_start = read_persistent_clock();

Do you know if the sync problem is an issue here?

=============================
Tim Bird
Architecture Group Chair, CE Linux Forum
Senior Staff Engineer, Sony Electronics
=============================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/