Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Thu 21 Aug 2014, 06:10
All times are UTC - 4
 Forum index » Advanced Topics » Cutting edge
Boot times measured in milliseconds, not minutes.
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [10 Posts]  
Author Message
technosaurus


Joined: 18 May 2008
Posts: 4335

PostPosted: Tue 22 Oct 2013, 04:29    Post subject:  Boot times measured in milliseconds, not minutes.  

First, I will explain why it takes so damn long to get to a desktop to begin with.

Since there are so many different reasons, I will go over these in the order they typically occur.

Loading Kernel
Traditionally:
First the bootloader has to load up from its various stages, process the command line and pass the buck to (in our case) the kernel (with optional initrd image)

Better:
boot directly with EFI
boot directly with coreboot -- filo
problems - currently difficult to automate EFI for a generic system and coreboot is complex enough to remain in the embedded systems developer domain

Running Kernel
Traditionally:
This part is really bad. Most kernels contain all kinds of built in stuff that is unnecessary for initial bringup, but then have several modules inside of an initrd image that need to be modprobed etc... just to boot it up.

Better:
Only include the parts necessary to mount the desired partition and run X (these should be around 1MB) It is almost always a safe bet to compress the kernel with lzop the small decompression overhead is compensated by the reduced time it takes to read the smaller image.

Bringing Up System
Traditionally:
We already touched on the initrd/initramfs, with the root filesystem, but if that was all it did, it wouldn't be too bad. Unfortunately for the casual desktop user the whole bringup process also involves a lot of setup and daemon process starting. I won't go into these (upstart, systemd, sysv,...) because all of these are basically unnecessary

Better:
On our EFI boot partition we create an init that mounts a devtmpfs, devpts, sys and proc then runs our xinit

Bringing Up X
Traditionally:
xinit does a bunch of stuff: Xorg goes through a whole detection/config process, a display manager, some configuration apps and daemons begin running and a full desktop with window manager starts up while preloading a bunch of stuff.

Better:
option 1: instead of respawning gettys, etc... use our "init" to keep X + a wm running and use the already specified autostart to handle daemons and background processes
option 2: If you cannot boot straight to your rootfs using EFI, build a subset of busybox/toybox and the basic parts of X (a static xfbdev/Xvesa + jwm multicall binary is less than 300kb compressed) into an initmpfs (not a ramfs - see Rob Landley's patch) and use it to bootstrap the rest.

That's pretty much it. I oversimplified a lot of things especially the process of shifting boot time daemons into autostart and setting up EFI. None of the tasks are that difficult, its just that there are a lot of them and some are time intensive (I hate building the kernel on my slow machines)

I initially started examining this way back in 2011 with Xvesa, jwm and a subset of busybox in under 1MB including the cut-down kernel and extraneous filesystem stuff. Now I am convinced that xfbdev is a better solution than xvesa (portable to arm, mips, ...) but we really need a kernel patch to make the framebuffer boot without input into its highest supported resolution. (Xvesa has the same problem, but can be reinitialized to higher resolutions with xrandr)

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Karl Godt


Joined: 20 Jun 2010
Posts: 3964
Location: Kiel,Germany

PostPosted: Tue 22 Oct 2013, 09:18    Post subject:  

Have only one machine that used efi and already scrapped it for grub .

Interesting read :
Quote:
Also, don't forget to disable the "Tickless system".
Question
- Puppy by default should be Tickless i think, have no kernel source right now to look into .

Quote:
cp /usr/src/linux/arch/x86/boot/bzImage /boot/efi/EFI/boot/bootx64.efi

I remeber that efi partition being somewhat 15MB in size .. , probably needs to enlarge that efi partition and that probably would render OEM machines bootless in WindowsOS regards .
Back to top
View user's profile Send private message Visit poster's website 
Ted Dog


Joined: 13 Sep 2005
Posts: 2312
Location: Heart of Texas

PostPosted: Tue 22 Oct 2013, 09:28    Post subject:  

Nope, the boot part on win8.0 is large enough to violate all the rule and boot frugal EFI directly, and yes its fast, like that, even if not planned. Razz I think EFI loads the whole part into memory.
Back to top
View user's profile Send private message 
veronicathecow


Joined: 21 Oct 2006
Posts: 533

PostPosted: Sat 26 Oct 2013, 08:13    Post subject:  

Would be nice to see faster boot times.
I was thinking of just no modprobing (unless you request it at the second and subsequent boot times) to cover the addition of new hardware (perhaps hold down a key to invoke it during boot and have an option to rescan from desktop?)
Also searching for puppy files takes ages and should just use the last file with again a boot option to search on hold down of a key?
But if technosaurus way works then that's a much better and faster solution. I will follow this thread. Thanks.
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 8150

PostPosted: Sat 26 Oct 2013, 09:39    Post subject:  

If you want faster recent puppies get to know bash and dive into its boot wrappers....its more than the odd modprobe. The sub folder search is a good one to start with but there is so much more that benefits from attention.. I halved the boot time of lucid by simply script hacking without any noticeable loss of functionality....and I'm sure newer versions are even more spaghetti bound judging by the feedback on the form....
Wrapping cotton wool around a problem does not solve the problem...the world of windows demonstrates that one.

bananas

mike
Back to top
View user's profile Send private message 
veronicathecow


Joined: 21 Oct 2006
Posts: 533

PostPosted: Sat 26 Oct 2013, 10:00    Post subject:  

Hi Mikeb, any chance you could share your hacks and where the files are? Thanks
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4335

PostPosted: Sat 26 Oct 2013, 10:13    Post subject:  

puppy's method (a union of readonly squashfs(s) and a writeable layer) should take a lot more time because it uses files on drives that have to be mounted 1st, yet it is on par with other mainstream distros. This is not a testament to how good puppy is (the init is a huge hack) but how poor the other implementations are. I am posting my notes and experiences improving the Linux experience here in case Iguleder, Ibidem, goingnuts, micko or other key players need them, because I will be venturing out on my own into BSDland and don't want the tricks to be lost.

The most important of the tricks can be observed in the 1Mb microsaurus image, but since then man things have occurred:
devtmpfs has gone mainstream,
the finit_module syscall has been added,
I discovered "readahead",
learned of the freedesktop autostart (and other) standards
others have refined the kernel parameters needed for booting without modprobing
and lots of other stuff I am forgetting, If you have a curiosity, just ask.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
mikeb


Joined: 23 Nov 2006
Posts: 8150

PostPosted: Sat 26 Oct 2013, 11:23    Post subject:  

It does take a long time compared to how it could be...not much point in making technical improvements elsewhere if you have a dog of hacked script or 3 bogging things down...my initrd init is 25 k rather than the 68 of the original lucid...just one example.

Since your info in aimed more generally rather than for puppy perhaps my comments are a little redundant.
Quote:

Hi Mikeb, any chance you could share your hacks and where the files are? Thanks

could do but it wouldn't be puppy (you can make windows safe and fast but then there are complaints that some really crappy function no longer exists...people want bad food even if ultimately it kills them) .... breaking away from someone else's restraints was the point of my comment to you and that in doing so significant changes can be made even at the scripting level. The chances are it would be right for you but to accommodate a wider audience takes significant testing. Without the backing of mainstream support you are on your own and all that entails.

mike
Back to top
View user's profile Send private message 
greengeek

Joined: 20 Jul 2010
Posts: 2477
Location: New Zealand

PostPosted: Sat 26 Oct 2013, 13:24    Post subject:  

technosaurus wrote:
I will be venturing out on my own into BSDland and don't want the tricks to be lost..
I get a sad, sad feeling that there is a risk of good Linux brains turning their backs on puppy because maintaining the 'Puppy' way of doing things can be inefficient.

Is there any chance that a new 'microsaurus' or 'bootasaurus' or something similar could become a super-efficient bootstrap that would then allow a "puppy" sfs to be overlayed over the top???

Who wouldnt want an OS that allowed the machine to boot really quickly to cli, then if desired, continue super quickly to an efficent minimalist gui, then if desired, continue into a Puppy sfs? (which could be as efficient / inefficient or bloated as any regular puppy happens to be...)

eg: like a minimalist Linux running a puppy (including all its newbie assisting wizards) as an sfs or in a VM of some sort.
Is such a thing technically possible?
.
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4335

PostPosted: Sat 26 Oct 2013, 17:31    Post subject:  

I honestly don't think the typical user wants a console at all (terminal yes, but no "console") so I focus on x. I can put my custom init.c and x startup helpers on github, but someone would need to modify the puppy installer to take full advantage... I can help with that, but I 'd really like to get it working on bsd too so we have another kernel choice before jumping the gun with an installer gui.
_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 1 [10 Posts]  
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Advanced Topics » Cutting edge
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0782s ][ Queries: 12 (0.0050s) ][ GZIP on ]