<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/2.0.12-alpha" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: fso-boot</title>
	<link>http://www.vanille-media.de/site/index.php/2010/02/02/fso-boot/</link>
	<description>Software Engineer - Author - Open Source Enthusiast</description>
	<pubDate>Fri, 30 Jul 2010 05:21:15 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.0.12-alpha</generator>

	<item>
		<title>by: luke kenneth casson</title>
		<link>http://www.vanille-media.de/site/index.php/2010/02/02/fso-boot/#comment-123563</link>
		<pubDate>Wed, 03 Feb 2010 16:07:21 +0000</pubDate>
		<guid>http://www.vanille-media.de/site/index.php/2010/02/02/fso-boot/#comment-123563</guid>
					<description>just to say, one of the important things i covered with the parallel init scripts i sorted out was the mess and insane delays caused by udevsettle.

part of the key reason for such dreadful startup times on the openmoko is the fact that the CPU throws away its cache on a context switch.  in combination with udev firing off scripts which can go to a process tree depth as high as 20 or 30, that's an _awful_ lot of time utterly utterly wasted on context switches.

and if you look at the number of devices with /dev/tty* such as pty etc. you find that there are at least 768 ttys and pseudo-ttys - 3 groups of 256 at least, plus a few more.

each and every single one of these pseudo-ttys must be initialised and waited for using /sbin/udevsettle.

even on a 1.6ghz Pentium 4 laptop, udevsettle for so many devices caused something like a 10-15 second addition to startup time.

so, the ABSOLUTE top priority when i was working with depinit was to write a "mini" udevsettle startup script which took care of all  other devices, and only initialised the first TEN of each of the pseudo TTYs.

this took only a couple of seconds.

THEN i had dependencies to start up other services AND initialise the remaining 700 or so pseudo-ttys in parallel.

then, also, because depinit is a parallel system, i was able to start up the X Server at the same time as kicking off other (unimportant as far as login) services such as Apache2 and even SSH server.

by the time the user actually logged in at the KDM x server, those services would have finished starting up.

on the 1.6ghz laptop i installed this on, the startup time to KDM was reduced to 25 seconds, which i achieved _well_ ahead of anyone else doing this kind of "startup optimisation".  it was over a year before gentoo announced they had got 15 second startup times.

and the shutdown time using depinit, thanks to it doing kill signals in parallel, is something like 3 to 5 seconds.

so overall it is a stunning advance over what is used now, and because depinit's core code is so simple, it hasn't actually needed any maintenance.

so, the fact that it's sitting there not being used by anyone is irrelevant: it's still useful.

_do_ look at it _before_ going and reinventing it, please.</description>
		<content:encoded><![CDATA[<p>just to say, one of the important things i covered with the parallel init scripts i sorted out was the mess and insane delays caused by udevsettle.</p>
<p>part of the key reason for such dreadful startup times on the openmoko is the fact that the CPU throws away its cache on a context switch.  in combination with udev firing off scripts which can go to a process tree depth as high as 20 or 30, that&#8217;s an _awful_ lot of time utterly utterly wasted on context switches.</p>
<p>and if you look at the number of devices with /dev/tty* such as pty etc. you find that there are at least 768 ttys and pseudo-ttys - 3 groups of 256 at least, plus a few more.</p>
<p>each and every single one of these pseudo-ttys must be initialised and waited for using /sbin/udevsettle.</p>
<p>even on a 1.6ghz Pentium 4 laptop, udevsettle for so many devices caused something like a 10-15 second addition to startup time.</p>
<p>so, the ABSOLUTE top priority when i was working with depinit was to write a &#8220;mini&#8221; udevsettle startup script which took care of all  other devices, and only initialised the first TEN of each of the pseudo TTYs.</p>
<p>this took only a couple of seconds.</p>
<p>THEN i had dependencies to start up other services AND initialise the remaining 700 or so pseudo-ttys in parallel.</p>
<p>then, also, because depinit is a parallel system, i was able to start up the X Server at the same time as kicking off other (unimportant as far as login) services such as Apache2 and even SSH server.</p>
<p>by the time the user actually logged in at the KDM x server, those services would have finished starting up.</p>
<p>on the 1.6ghz laptop i installed this on, the startup time to KDM was reduced to 25 seconds, which i achieved _well_ ahead of anyone else doing this kind of &#8220;startup optimisation&#8221;.  it was over a year before gentoo announced they had got 15 second startup times.</p>
<p>and the shutdown time using depinit, thanks to it doing kill signals in parallel, is something like 3 to 5 seconds.</p>
<p>so overall it is a stunning advance over what is used now, and because depinit&#8217;s core code is so simple, it hasn&#8217;t actually needed any maintenance.</p>
<p>so, the fact that it&#8217;s sitting there not being used by anyone is irrelevant: it&#8217;s still useful.</p>
<p>_do_ look at it _before_ going and reinventing it, please.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: luke kenneth casson</title>
		<link>http://www.vanille-media.de/site/index.php/2010/02/02/fso-boot/#comment-123562</link>
		<pubDate>Wed, 03 Feb 2010 15:47:29 +0000</pubDate>
		<guid>http://www.vanille-media.de/site/index.php/2010/02/02/fso-boot/#comment-123562</guid>
					<description>michael, hi,

richard lightman already did a complete and extremely thorough job on depinit, which he rewrote back in 2003.

it is increedibly comprehensive, and was adapted into the "linux from scratch" project.

depinit is a parallel boot system, with *automatic* restart of services, and unlike the crap /sbin/init that it replaces, it catches ALL signals and allows you to react to all of them.

so not just SIGQUIT i mean absolutely EVERY signal is caught.

it's also possible to do recursive testing: you can run depinit under depinit, i.e. you don't have to run it as process 1, but there are limitations (due to the linux kernel, ironically) if you do that.

don't for goodness sake go writing yet another init system until you've evaluated depinit.</description>
		<content:encoded><![CDATA[<p>michael, hi,</p>
<p>richard lightman already did a complete and extremely thorough job on depinit, which he rewrote back in 2003.</p>
<p>it is increedibly comprehensive, and was adapted into the &#8220;linux from scratch&#8221; project.</p>
<p>depinit is a parallel boot system, with *automatic* restart of services, and unlike the crap /sbin/init that it replaces, it catches ALL signals and allows you to react to all of them.</p>
<p>so not just SIGQUIT i mean absolutely EVERY signal is caught.</p>
<p>it&#8217;s also possible to do recursive testing: you can run depinit under depinit, i.e. you don&#8217;t have to run it as process 1, but there are limitations (due to the linux kernel, ironically) if you do that.</p>
<p>don&#8217;t for goodness sake go writing yet another init system until you&#8217;ve evaluated depinit.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: Philip Hands</title>
		<link>http://www.vanille-media.de/site/index.php/2010/02/02/fso-boot/#comment-123559</link>
		<pubDate>Wed, 03 Feb 2010 15:08:03 +0000</pubDate>
		<guid>http://www.vanille-media.de/site/index.php/2010/02/02/fso-boot/#comment-123559</guid>
					<description>You might want to have a look at depinit (a dependency based init program) or one of the several other existing init alternatives.

I'd be stunned if you find that you get any noticeable speedup from replacing init, when compared with doing something like getting init to just run fso-boot alone (by defining a new runlevel, and making that default, say).</description>
		<content:encoded><![CDATA[<p>You might want to have a look at depinit (a dependency based init program) or one of the several other existing init alternatives.</p>
<p>I&#8217;d be stunned if you find that you get any noticeable speedup from replacing init, when compared with doing something like getting init to just run fso-boot alone (by defining a new runlevel, and making that default, say).
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: mickey</title>
		<link>http://www.vanille-media.de/site/index.php/2010/02/02/fso-boot/#comment-123549</link>
		<pubDate>Tue, 02 Feb 2010 15:28:02 +0000</pubDate>
		<guid>http://www.vanille-media.de/site/index.php/2010/02/02/fso-boot/#comment-123549</guid>
					<description>For sure, the slower the hardware is the more the impact is.</description>
		<content:encoded><![CDATA[<p>For sure, the slower the hardware is the more the impact is.
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: sam</title>
		<link>http://www.vanille-media.de/site/index.php/2010/02/02/fso-boot/#comment-123548</link>
		<pubDate>Tue, 02 Feb 2010 15:24:47 +0000</pubDate>
		<guid>http://www.vanille-media.de/site/index.php/2010/02/02/fso-boot/#comment-123548</guid>
					<description>:-)

will this help gta02 too?</description>
		<content:encoded><![CDATA[<p>:-)</p>
<p>will this help gta02 too?
</p>
]]></content:encoded>
				</item>
	<item>
		<title>by: fylefou</title>
		<link>http://www.vanille-media.de/site/index.php/2010/02/02/fso-boot/#comment-123544</link>
		<pubDate>Tue, 02 Feb 2010 06:44:21 +0000</pubDate>
		<guid>http://www.vanille-media.de/site/index.php/2010/02/02/fso-boot/#comment-123544</guid>
					<description>very good news!!! i waiting for your result!! go on!</description>
		<content:encoded><![CDATA[<p>very good news!!! i waiting for your result!! go on!
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
