Re: [PATCH] RealTimeSync Patch
Andrew Morton wrote: > Elias Kesh <[EMAIL PROTECTED]> wrote: >> Looking at the archives I see that a an intel patch >> was submitted back in October but I am unable to >> determine what the resolution was. > > What patch was that? http://lkml.org/lkml/2004/10/29/332 > OK. But adding fiddle new config options and ifdefs is really, really a > last resort. Much better to fix the code by making it smarter, or > runtime-selectable, or by avoiding the delays if we see that they're not > really needed (like: certain hardware isn't present) or whatever. ... > Better would be to work out whether the underlying platform really, realy > needs the delay and if so only enable it on those platforms, preferable via > a runtime decision. > > But then, I don't know what that synchronisation code is actually trying to > do. The short of it: it's trying to make the system time as accurate as possible, by delaying setting the system time until the actual RTC seconds rollover. Without this synch. operation, the system time is within a second of the RTC value anyways. With regard to the actual feature request, I agree that a config option should be a last resort. I'd rather just eliminate the synchronization altogether, and let post-boot code fix the system time (sub-second) accuracy, if it's needed. IMHO it won't be needed in embedded scenarios and will very seldom be needed in other use areas (server and desktop). Many desktop users already get their system time accuracy from an external source (ntp) now anyways. We can submit a patch to *remove* code for multiple architectures very quickly! ;-) > In general, it's taking wy to long to get all > these CELinux patches into the outside world. Thanks > for getting this one on the wires. Let's > get them all done and finish this thing. The forum, of late, has been taking a different approach. While the forum has a few patches we want to push ourselves directly, we now focus more effort on getting individual member companies (and individual engineers) to participate directly in projects of interest. As one example, a Sony engineer has participated quite heavily in the high resolution timers project over the last year or so. Only occasionally, when there does not appear to be another suitable project in an area (such as fast booting), do we manage a patch inside the forum and submit it from there. But I agree that in some areas the forum has been quite slow to push these patches. This RTC synch. issue was first discussed on LKML in May of 2004. See: http://lkml.org/lkml/2004/5/7/180 In a perfect world, a patch would have shown up within a week of that discussion. For reasons too long to discuss here, it took 5 months instead, and then another 9 months to submit this. So, yes, CELF and some of it's members clearly have some areas to improve on in working with the open source model. I'm sincerely grateful for the help and encouragement! -- Tim = 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RealTimeSync Patch
>http://tree.celinuxforum.org/CelfPubWiki/RTCNoSync The webpage says... >One tradeoff in making this modification is that the time stored by the Linux >kernel is no longer completely synchronized If one runs "hwclock", the delta is barely 0.000, but always some more or some less, so it should not matter. Jan Engelhardt -- - 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/
Re: [PATCH] RealTimeSync Patch
http://tree.celinuxforum.org/CelfPubWiki/RTCNoSync The webpage says... One tradeoff in making this modification is that the time stored by the Linux kernel is no longer completely synchronized If one runs hwclock, the delta is barely 0.000, but always some more or some less, so it should not matter. Jan Engelhardt -- - 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/
Re: [PATCH] RealTimeSync Patch
Andrew Morton wrote: Elias Kesh [EMAIL PROTECTED] wrote: Looking at the archives I see that a an intel patch was submitted back in October but I am unable to determine what the resolution was. What patch was that? http://lkml.org/lkml/2004/10/29/332 OK. But adding fiddle new config options and ifdefs is really, really a last resort. Much better to fix the code by making it smarter, or runtime-selectable, or by avoiding the delays if we see that they're not really needed (like: certain hardware isn't present) or whatever. ... Better would be to work out whether the underlying platform really, realy needs the delay and if so only enable it on those platforms, preferable via a runtime decision. But then, I don't know what that synchronisation code is actually trying to do. The short of it: it's trying to make the system time as accurate as possible, by delaying setting the system time until the actual RTC seconds rollover. Without this synch. operation, the system time is within a second of the RTC value anyways. With regard to the actual feature request, I agree that a config option should be a last resort. I'd rather just eliminate the synchronization altogether, and let post-boot code fix the system time (sub-second) accuracy, if it's needed. IMHO it won't be needed in embedded scenarios and will very seldom be needed in other use areas (server and desktop). Many desktop users already get their system time accuracy from an external source (ntp) now anyways. We can submit a patch to *remove* code for multiple architectures very quickly! ;-) In general, it's taking wy to long to get all these CELinux patches into the outside world. Thanks for getting this one on the wires. Let's get them all done and finish this thing. The forum, of late, has been taking a different approach. While the forum has a few patches we want to push ourselves directly, we now focus more effort on getting individual member companies (and individual engineers) to participate directly in projects of interest. As one example, a Sony engineer has participated quite heavily in the high resolution timers project over the last year or so. Only occasionally, when there does not appear to be another suitable project in an area (such as fast booting), do we manage a patch inside the forum and submit it from there. But I agree that in some areas the forum has been quite slow to push these patches. This RTC synch. issue was first discussed on LKML in May of 2004. See: http://lkml.org/lkml/2004/5/7/180 In a perfect world, a patch would have shown up within a week of that discussion. For reasons too long to discuss here, it took 5 months instead, and then another 9 months to submit this. So, yes, CELF and some of it's members clearly have some areas to improve on in working with the open source model. I'm sincerely grateful for the help and encouragement! -- Tim = 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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] RealTimeSync Patch
Elias Kesh <[EMAIL PROTECTED]> wrote: > > Hello, > > I would like to get some feedback on this patch for the kernel. It's sole > purpose is to help in reducing boot time by not waiting to synchronize the > clock edge with the hardware clock. This when combined with other boot > reduction patched can bring the kernel boot time to well under 10 seconds, in > most cases two or three seconds. In a desktop system this patch is probably > insignificant, howerver several patches like this in a set top box or cell > phone will be signicant. Please wordwrap your emails at column 72 or thereabouts. > I understand that there may be some concerns with patches like these so I > would like to start a discussion so that I can better understand what the > issues are. The members of the CELinux Forum have quite a bit we would like > to contribute. You should send the patches to this mailing list, just as you have done here. > Looking at the archives I see that a an intel patch was submitted back in > October but I am unable to determine what the resolution was. What patch was that? > This patch included is for PPC but other architecutres are available on the > patch web site below. I get connection refused from tree.celinuxforum.org > Detailed information on the patch can be found here: > http://tree.celinuxforum.org/CelfPubWiki/RTCNoSync > > In addition, other patches for boot time reduction can be found here: > http://tree.celinuxforum.org/CelfPubWiki/PatchArchive Finish the patches and just send them. No fuss. See http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt for a few details. > * > Fast boot options (FASTBOOT) [N/y/?] (NEW) y > Disable synch on read of Real Time Clock (RTC_NO_SYNC) [N/y/?] (NEW) y > This particular feature seems to be ppc-specific and hence the folks at [EMAIL PROTECTED] should be involved. Probably the CONFIG_RTC_NO_SYNC Kconfig option should be in arch/ppc/Kconfig - one would need to see all the patches to determine that. It might be better to use a kernel boot option rather than another compile-time option for this - you'd need to discuss that with other ppc people. Or perhaps the code in there is just being dumb and can be fixed. In general, it's taking wy to long to get all these CELinux patches into the outside world. Thanks for getting this one on the wires. Let's get them all done and finish this thing. - 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/
[PATCH] RealTimeSync Patch
Hello,
I would like to get some feedback on this patch for the kernel. It's sole
purpose is to help in reducing boot time by not waiting to synchronize the
clock edge with the hardware clock. This when combined with other boot
reduction patched can bring the kernel boot time to well under 10 seconds, in
most cases two or three seconds. In a desktop system this patch is probably
insignificant, howerver several patches like this in a set top box or cell
phone will be signicant.
I understand that there may be some concerns with patches like these so I
would like to start a discussion so that I can better understand what the
issues are. The members of the CELinux Forum have quite a bit we would like to
contribute.
Looking at the archives I see that a an intel patch was submitted back in
October but I am unable to determine what the resolution was.
This patch included is for PPC but other architecutres are available on the
patch web site below.
Detailed information on the patch can be found here:
http://tree.celinuxforum.org/CelfPubWiki/RTCNoSync
In addition, other patches for boot time reduction can be found here:
http://tree.celinuxforum.org/CelfPubWiki/PatchArchive
Elias Kesh
[EMAIL PROTECTED]
* Fast boot options
*
Fast boot options (FASTBOOT) [N/y/?] (NEW) y
Disable synch on read of Real Time Clock (RTC_NO_SYNC) [N/y/?] (NEW) y
diff -u -pruN -X ../dontdiff linux-2.6.12/arch/ppc/kernel/time.c
linux-2.6.12_rtc_patch/arch/ppc/kernel/time.c
--- linux-2.6.12/arch/ppc/kernel/time.c 2005-06-17 21:48:29.0 +0200
+++ linux-2.6.12_rtc_patch/arch/ppc/kernel/time.c 2005-07-02
00:27:37.0 +0200
@@ -282,8 +282,12 @@ EXPORT_SYMBOL(do_settimeofday);
/* This function is only called on the boot processor */
void __init time_init(void)
{
- time_t sec, old_sec;
- unsigned old_stamp, stamp, elapsed;
+ time_t sec;
+ unsigned stamp;
+#ifndef CONFIG_RTC_NO_SYNC
+ time_t old_sec;
+ unsigned old_stamp, elapsed;
+#endif
if (ppc_md.time_init != NULL)
time_offset = ppc_md.time_init();
@@ -308,6 +312,7 @@ void __init time_init(void)
stamp = get_native_tbl();
if (ppc_md.get_rtc_time) {
sec = ppc_md.get_rtc_time();
+#ifndef CONFIG_RTC_NO_SYNC
elapsed = 0;
do {
old_stamp = stamp;
@@ -320,6 +325,7 @@ void __init time_init(void)
} while ( sec == old_sec && elapsed < 2*HZ*tb_ticks_per_jiffy);
if (sec==old_sec)
printk("Warning: real time clock seems stuck!\n");
+#endif
xtime.tv_sec = sec;
xtime.tv_nsec = 0;
/* No update now, we just read the time from the RTC ! */
diff -u -pruN -X ../dontdiff linux-2.6.12/init/Kconfig
linux-2.6.12_rtc_patch/init/Kconfig
--- linux-2.6.12/init/Kconfig 2005-06-17 21:48:29.0 +0200
+++ linux-2.6.12_rtc_patch/init/Kconfig 2005-07-02 00:27:37.0 +0200
@@ -275,6 +275,33 @@ config KALLSYMS_EXTRA_PASS
reported. KALLSYMS_EXTRA_PASS is only a temporary workaround while
you wait for kallsyms to be fixed.
+menuconfig FASTBOOT
+ bool "Fast boot options"
+ help
+ Say Y here to select among various options that can decrease
+ kernel boot time. These options may involve providing
+ hardcoded values for some parameters that the kernel usually
+ determines automatically.
+
+ This option is useful primarily on embedded systems.
+
+ If unsure, say N.
+
+config RTC_NO_SYNC
+ bool "Disable synch on read of Real Time Clock" if FASTBOOT
+ default n
+ help
+ The Real Time Clock is read aligned by default. That means a
+ series of reads of the RTC are done until it's verified that
+ the RTC's state has just changed. If you enable this feature,
+ this synchronization will not be performed. The result is that
+ the machine will boot up to 1 second faster.
+
+ A drawback is that, with this option enabled, your system
+ clock may drift from the correct value over the course
+ of several boot cycles (under certain circumstances).
+
+ If unsure, say N.
config PRINTK
default y
-
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/
[PATCH] RealTimeSync Patch
Hello,
I would like to get some feedback on this patch for the kernel. It's sole
purpose is to help in reducing boot time by not waiting to synchronize the
clock edge with the hardware clock. This when combined with other boot
reduction patched can bring the kernel boot time to well under 10 seconds, in
most cases two or three seconds. In a desktop system this patch is probably
insignificant, howerver several patches like this in a set top box or cell
phone will be signicant.
I understand that there may be some concerns with patches like these so I
would like to start a discussion so that I can better understand what the
issues are. The members of the CELinux Forum have quite a bit we would like to
contribute.
Looking at the archives I see that a an intel patch was submitted back in
October but I am unable to determine what the resolution was.
This patch included is for PPC but other architecutres are available on the
patch web site below.
Detailed information on the patch can be found here:
http://tree.celinuxforum.org/CelfPubWiki/RTCNoSync
In addition, other patches for boot time reduction can be found here:
http://tree.celinuxforum.org/CelfPubWiki/PatchArchive
Elias Kesh
[EMAIL PROTECTED]
* Fast boot options
*
Fast boot options (FASTBOOT) [N/y/?] (NEW) y
Disable synch on read of Real Time Clock (RTC_NO_SYNC) [N/y/?] (NEW) y
diff -u -pruN -X ../dontdiff linux-2.6.12/arch/ppc/kernel/time.c
linux-2.6.12_rtc_patch/arch/ppc/kernel/time.c
--- linux-2.6.12/arch/ppc/kernel/time.c 2005-06-17 21:48:29.0 +0200
+++ linux-2.6.12_rtc_patch/arch/ppc/kernel/time.c 2005-07-02
00:27:37.0 +0200
@@ -282,8 +282,12 @@ EXPORT_SYMBOL(do_settimeofday);
/* This function is only called on the boot processor */
void __init time_init(void)
{
- time_t sec, old_sec;
- unsigned old_stamp, stamp, elapsed;
+ time_t sec;
+ unsigned stamp;
+#ifndef CONFIG_RTC_NO_SYNC
+ time_t old_sec;
+ unsigned old_stamp, elapsed;
+#endif
if (ppc_md.time_init != NULL)
time_offset = ppc_md.time_init();
@@ -308,6 +312,7 @@ void __init time_init(void)
stamp = get_native_tbl();
if (ppc_md.get_rtc_time) {
sec = ppc_md.get_rtc_time();
+#ifndef CONFIG_RTC_NO_SYNC
elapsed = 0;
do {
old_stamp = stamp;
@@ -320,6 +325,7 @@ void __init time_init(void)
} while ( sec == old_sec elapsed 2*HZ*tb_ticks_per_jiffy);
if (sec==old_sec)
printk(Warning: real time clock seems stuck!\n);
+#endif
xtime.tv_sec = sec;
xtime.tv_nsec = 0;
/* No update now, we just read the time from the RTC ! */
diff -u -pruN -X ../dontdiff linux-2.6.12/init/Kconfig
linux-2.6.12_rtc_patch/init/Kconfig
--- linux-2.6.12/init/Kconfig 2005-06-17 21:48:29.0 +0200
+++ linux-2.6.12_rtc_patch/init/Kconfig 2005-07-02 00:27:37.0 +0200
@@ -275,6 +275,33 @@ config KALLSYMS_EXTRA_PASS
reported. KALLSYMS_EXTRA_PASS is only a temporary workaround while
you wait for kallsyms to be fixed.
+menuconfig FASTBOOT
+ bool Fast boot options
+ help
+ Say Y here to select among various options that can decrease
+ kernel boot time. These options may involve providing
+ hardcoded values for some parameters that the kernel usually
+ determines automatically.
+
+ This option is useful primarily on embedded systems.
+
+ If unsure, say N.
+
+config RTC_NO_SYNC
+ bool Disable synch on read of Real Time Clock if FASTBOOT
+ default n
+ help
+ The Real Time Clock is read aligned by default. That means a
+ series of reads of the RTC are done until it's verified that
+ the RTC's state has just changed. If you enable this feature,
+ this synchronization will not be performed. The result is that
+ the machine will boot up to 1 second faster.
+
+ A drawback is that, with this option enabled, your system
+ clock may drift from the correct value over the course
+ of several boot cycles (under certain circumstances).
+
+ If unsure, say N.
config PRINTK
default y
-
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/
Re: [PATCH] RealTimeSync Patch
Elias Kesh [EMAIL PROTECTED] wrote: Hello, I would like to get some feedback on this patch for the kernel. It's sole purpose is to help in reducing boot time by not waiting to synchronize the clock edge with the hardware clock. This when combined with other boot reduction patched can bring the kernel boot time to well under 10 seconds, in most cases two or three seconds. In a desktop system this patch is probably insignificant, howerver several patches like this in a set top box or cell phone will be signicant. Please wordwrap your emails at column 72 or thereabouts. I understand that there may be some concerns with patches like these so I would like to start a discussion so that I can better understand what the issues are. The members of the CELinux Forum have quite a bit we would like to contribute. You should send the patches to this mailing list, just as you have done here. Looking at the archives I see that a an intel patch was submitted back in October but I am unable to determine what the resolution was. What patch was that? This patch included is for PPC but other architecutres are available on the patch web site below. I get connection refused from tree.celinuxforum.org Detailed information on the patch can be found here: http://tree.celinuxforum.org/CelfPubWiki/RTCNoSync In addition, other patches for boot time reduction can be found here: http://tree.celinuxforum.org/CelfPubWiki/PatchArchive Finish the patches and just send them. No fuss. See http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt for a few details. * Fast boot options (FASTBOOT) [N/y/?] (NEW) y Disable synch on read of Real Time Clock (RTC_NO_SYNC) [N/y/?] (NEW) y This particular feature seems to be ppc-specific and hence the folks at [EMAIL PROTECTED] should be involved. Probably the CONFIG_RTC_NO_SYNC Kconfig option should be in arch/ppc/Kconfig - one would need to see all the patches to determine that. It might be better to use a kernel boot option rather than another compile-time option for this - you'd need to discuss that with other ppc people. Or perhaps the code in there is just being dumb and can be fixed. In general, it's taking wy to long to get all these CELinux patches into the outside world. Thanks for getting this one on the wires. Let's get them all done and finish this thing. - 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/
