Debian boots in 0.87 seconds:
http://linuxgizmos.com/headless-arm9-sbc-boots-linux-in-less-than-one-second... http://www.embeddedarm.com/products/board-detail.php?product=TS-7250-V2
Good if this could be force marched to happen EOMA / Allwinner CPU.
A complete world game changer and a lot of funds will get released for dormant projects that need fast boot + linux.
Crowd funding world would go beserk :)
On Tue, Dec 2, 2014 at 3:37 PM, joem joem@martindale-electric.co.uk wrote:
Debian boots in 0.87 seconds:
... not quite. they say it boots to a busybox shell in 0.87 seconds, and they can *supply* debian wheezy for it. they most likely boot direct rather than use u-boot. or if they use u-boot it's also been configured to minimal settings.
http://linuxgizmos.com/headless-arm9-sbc-boots-linux-in-less-than-one-second... http://www.embeddedarm.com/products/board-detail.php?product=TS-7250-V2
Good if this could be force marched to happen EOMA / Allwinner CPU.
A complete world game changer and a lot of funds will get released for dormant projects that need fast boot + linux.
it's doable - it's quite a committment in time and effort which i'd prefer (personally) to see an advance financial committment matched to it.
to get any OS (such as debian) to boot very very fast you need to make some quite significant modifications. udev has to go (entirely) in favour of a static set of /dev/* entries, for example. the kernel has to be customised to minimise the number of extra pseudo ttys. initrd has to go: everything must be in a static monstrously-large kernel (which itself becomes problematic as that adversely affects load time).
so it's a balancing act that has already moved outside of the mainstream debian (or other OS) infrastructure and purpose, that then needs maintaining.
all of which takes time, hence why i would (personally) like to see some up-front payment before committing time to such an idea.
l.
On Tue, 2014-12-02 at 16:19 +0000, Luke Kenneth Casson Leighton wrote:
On Tue, Dec 2, 2014 at 3:37 PM, joem joem@martindale-electric.co.uk wrote:
Debian boots in 0.87 seconds:
... not quite. they say it boots to a busybox shell in 0.87 seconds,
Good enough to run a program that puts up a background?
and they can *supply* debian wheezy for it. they most likely boot direct rather than use u-boot. or if they use u-boot it's also been configured to minimal settings.
http://linuxgizmos.com/headless-arm9-sbc-boots-linux-in-less-than-one-second... http://www.embeddedarm.com/products/board-detail.php?product=TS-7250-V2
Good if this could be force marched to happen EOMA / Allwinner CPU.
A complete world game changer and a lot of funds will get released for dormant projects that need fast boot + linux.
it's doable - it's quite a committment in time and effort which i'd prefer (personally) to see an advance financial committment matched to it.
to get any OS (such as debian) to boot very very fast you need to make some quite significant modifications. udev has to go (entirely) in favour of a static set of /dev/* entries, for example. the kernel has to be customised to minimise the number of extra pseudo ttys. initrd has to go: everything must be in a static monstrously-large kernel (which itself becomes problematic as that adversely affects load time).
so it's a balancing act that has already moved outside of the mainstream debian (or other OS) infrastructure and purpose, that then needs maintaining.
What about an open sourced script that can do this feat? Everybody throws in their know how.
all of which takes time, hence why i would (personally) like to see some up-front payment before committing time to such an idea.
Name a figure.
On Tue, Dec 2, 2014 at 7:35 PM, joem joem@martindale-electric.co.uk wrote:
On Tue, 2014-12-02 at 16:19 +0000, Luke Kenneth Casson Leighton wrote:
On Tue, Dec 2, 2014 at 3:37 PM, joem joem@martindale-electric.co.uk wrote:
Debian boots in 0.87 seconds:
... not quite. they say it boots to a busybox shell in 0.87 seconds,
Good enough to run a program that puts up a background?
yeah indeed. if you only have one program to run then it's fantastic to have it starting up in like one or two seconds. i remember compiling up webkit for a very special ARM9 processor (with access to1666mhz DDR3 RAM!!) and that was starting up in seconds: i just never got round to optimising the OS [it was a research project....]
so it's a balancing act that has already moved outside of the mainstream debian (or other OS) infrastructure and purpose, that then needs maintaining.
What about an open sourced script that can do this feat?
there was an article a while back published by.. ahh who was it... montavista or redhat... it was 6 or 7 years ago.... there is quite a lot that needs to be done.
all of which takes time, hence why i would (personally) like to see some up-front payment before committing time to such an idea.
Name a figure.
me? GBP 400 a day, minimum 5 days to get something reasonably quick (low-hanging fruit so to speak), going beyond the easiest stuff i'd be happy to continue for up to 3-4 weeks to tackle some of the harder/more-complex stuff.
l.
On Tue, 2014-12-02 at 19:54 +0000, Luke Kenneth Casson Leighton wrote:
Debian boots in 0.87 seconds:
... not quite. they say it boots to a busybox shell in 0.87 seconds,
Good enough to run a program that puts up a background?
yeah indeed. if you only have one program to run then it's fantastic to have it starting up in like one or two seconds.
Perfect for hand held gadgets we build that are wanting an Android like colour touch interface program written in Gambas3 to start up and run in under 3 seconds.
so it's a balancing act that has already moved outside of the mainstream debian (or other OS) infrastructure and purpose, that then needs maintaining.
What about an open sourced script that can do this feat?
there was an article a while back published by.. ahh who was it... montavista or redhat... it was 6 or 7 years ago.... there is quite a lot that needs to be done.
all of which takes time, hence why i would (personally) like to see some up-front payment before committing time to such an idea.
Name a figure.
me? GBP 400 a day, minimum 5 days to get something reasonably quick (low-hanging fruit so to speak), going beyond the easiest stuff i'd be happy to continue for up to 3-4 weeks to tackle some of the harder/more-complex stuff.
I'll band a 10k figure about to see if anyone bites.
On Tue, Dec 2, 2014 at 8:45 PM, joem joem@martindale-electric.co.uk wrote:
On Tue, 2014-12-02 at 19:54 +0000, Luke Kenneth Casson Leighton wrote:
Debian boots in 0.87 seconds:
... not quite. they say it boots to a busybox shell in 0.87 seconds,
Good enough to run a program that puts up a background?
yeah indeed. if you only have one program to run then it's fantastic to have it starting up in like one or two seconds.
Perfect for hand held gadgets we build that are wanting an Android like colour touch interface program written in Gambas3 to start up and run in under 3 seconds.
exactly. but as peter says, for the "simplistic" solutions: go beyond the exact requirements and it gets... complicated.
I'll band a 10k figure about to see if anyone bites.
star. i will be able to do something half-way decent that will cope with a lot more scenarios for that.
l.
joem wrote:
What about an open sourced script that can do this feat? Everybody throws in their know how.
The problem is getting a fast boot time is really a matter of deciding what you can live without or at least start asyncronously after your main application has started, then ruthlessly optimising what is left for your specific case.
So the result is a system that boots to a specific application very quickly but may be horriblly broken if the application or hardware used changes.
On Tue, Dec 2, 2014 at 8:02 PM, peter green plugwash@p10link.net wrote:
joem wrote:
What about an open sourced script that can do this feat? Everybody throws in their know how.
The problem is getting a fast boot time is really a matter of deciding what you can live without or at least start asyncronously after your main application has started, then ruthlessly optimising what is left for your specific case.
So the result is a system that boots to a specific application very quickly but may be horriblly broken if the application or hardware used changes.
there's a parallel init system i worked with that i adapted in 2006 to boot a 1.5ghz single-core pentium 3 system to x-windows in around 20 seconds. shutdown was under *three* seconds. instead of replacing udev i split the udevadm startup into two "settle" sections: one critical (disks, network, first 10 pseudo-ttys) and one-for-everything-else. x-windows and ssh were dependent on the one-for-everything-else, and networking, disk mounting etc were dependent on the critical one.
the only problem you've got with parallel init systems is that they rely on the processor being "modern" i.e. to have decent context-switching. an ARM9 is *NOT* a modern processor. every context-switch THROWS AWAY the cache. a Cortex A7 / A9 we might have better luck
l.
On Tue, 2014-12-02 at 20:02 +0000, peter green wrote:
What about an open sourced script that can do this feat? Everybody throws in their know how.
The problem is getting a fast boot time is really a matter of deciding what you can live without or at least start asyncronously after your main application has started, then ruthlessly optimising what is left for your specific case.
So the result is a system that boots to a specific application very quickly but may be horriblly broken if the application or hardware used changes.
Idea: (As a fan of Gambas I am led to believe its 1.5x faster than python.) So a gambas GUI program with lots of visual basic like scripts can cobble a workable configurable GUI per board and then you would just check a list of features that must work, and it goes off and creates an almighty bash script to hack a fresh install of Debian down to its minimal innards.
+++ Luke Kenneth Casson Leighton [2014-12-02 16:19 +0000]:
On Tue, Dec 2, 2014 at 3:37 PM, joem joem@martindale-electric.co.uk wrote:
Debian boots in 0.87 seconds:
to get any OS (such as debian) to boot very very fast you need to make some quite significant modifications. udev has to go (entirely) in favour of a static set of /dev/* entries, for example. the kernel has to be customised to minimise the number of extra pseudo ttys. initrd has to go: everything must be in a static monstrously-large kernel (which itself becomes problematic as that adversely affects load time).
Exatly. fast booting is a direct trade-off between generality and speed. Nearly everything you do to make a standard image that will boot on anything, also makes the boot slower. Nearly everything you do to make it go faster involves removing options, removing detection code and pre-configuring things. Thus whilst it is indeed possible to make linux boot very fast indeed (see numerous Embedded Linux Conference talks on the subject) it comes by making very hardware/case-specific optimisations.
That is often worth the effort for specific cases, but always involves divergence for a binary distro (less so for a source distro) that you then need to maintain if you want to keep that feature working on new releases.
All that said, I'm sure that study of Debian and options for having standardised ways of improving boottime would be worthwhile. I bet there are things we could do to at least make this easier and possibly make things go faster _without_ undue loss of generality, especially as there has been a pile of change recently in the boot process (don't mention the war! :-)
Wookey
On Wed, Dec 3, 2014 at 3:29 PM, Wookey wookey@wookware.org wrote:
All that said, I'm sure that study of Debian and options for having standardised ways of improving boottime would be worthwhile. I bet there are things we could do to at least make this easier and possibly make things go faster _without_ undue loss of generality, especially as there has been a pile of change recently in the boot process (don't mention the war! :-)
... whatever you do, don't mention ze war :)
yes. wookey, there is *definitely* something that can be done, unfortunately i lost the work back in 2006 (and would have to recreate it). basically udev right now creates hundreds of nodes and has to "settle".
this "settling" *can* be sub-divided into at least two groups. you can look in the udev event trigger location (somewhere in /sys) and instead of "is empty subdirectory" use "grep sd* net* tty?" and other tricks.
in this way it's possible to have (at the very least) mounting and networking come up a good few seconds *before* everything else. you *do not* need to delay networking or early mount just because 768 pseudo-ttys have to be created.
and it _does_ take a long time because of udev spawning bash/dash scripts, which then spawn more bash scripts... back in 2004 i think i saw a stack of bash scripts *THIRTY DEEP* on a old Pentium 90 system - it was something like *2 MINUTES* for udev to stop f******g about.
whilst there have been many improvements in hardware context-switching for x86 systems, other processor architectures *do not* have such good context-switching (extreme case: ARM9 as you well know) so on such systems the effects of the assumptions "everything works fine on x86" are much more marked.
l.
arm-netbook@lists.phcomp.co.uk
-
joem -
Luke Kenneth Casson Leighton -
peter green -
Stefan Monnier -
Wookey