Beta test New Init system, realy improved boot time.

[JimmyW]

I have written a new replacement to sysvinit, and the rc-scripts i c-code, that can execute code in parralell, and uses a mutch smarter interface, and new thinking.

Feel free to try it out at: Http://initng.thinktux.net/
Note: Gentoo ebuild added to homepage.


This Thread is moving to a delecated server, You are all welcome to http://forum.initng.thinktux.net/ where we in sorted cetegorys can discuss initng.

Welcome!



Please DONT Post here.


#news.
Sorry for a late release, things got verry unstable, and this is not so mutch better, but i think its mor stable that initng-0.1.1


if you got problems, try #rm -r /etc/initng,#rm -r /lib/initng, #make uninstall and then #make install or #make link-install again.

Always consider using latest svn version

#svn co http://jw.dyndns.org/initng/svn/initng
#make
#make uninstall
#make install or #make link-install


Please get me some feedback!

/Jimmy Wennlund

Version History:
---------------
2005/06/07 03:00 (Swedish timezone GMT+2)
initng-0.1.2 - A lot has happend.
* Found some bugs with valgrind, realy,
nice tool.
* disable signals, in forks.
* List modules, with ngc -l
* Load module, with ngc -o "full_path"
* new version of ngc, skipps fifo.
* print_service, true ngc, insted out
to terminal
* Dont load same module twice.
* ngc got some cleanup.
* every service, will remember its filename
* new manuals ngc.8 initng.8
* Fixed a nasty bug, to small allocation.
* New installation instructions
* try /dev/tty12 when wont find /dev/vc/12
* fix_variables, is now used in pid file, args,
exec. can be dynamic $NAME
* Dynamlicly reload data from disk, if flushed
* check if udevstart exits, befor mounting /dev
* Updated Makefiles, now installs correctly
* ngc -y kills all services, that dont
remains into current runlevel
* ngc wont print all options, ngc -h will
* dash plugin added, tnx neuron, dont realy
work yet.
* Added main-loop hook.
* Full plugin framework rewrite.
* Moved bash_exec and s_exec to plugins.
* added option, also_stop and also_start,
also_stop will stop another service, if
this service got a stop request
* moved som code from handler.c to killed_handler.c
* wrote up plugin.
* a readme, for plugins.
* libsplash got some work, currently broaken.
* more then one DAEMON or START, make initng probe
for one working.
* sysvinit reboot fixes.
* Random buggfixes.

[i92guboj]

I will be pleased to test you. Tomorrow I will tell you how it works, today is just too late here.

[irondog]

Cewl.

Remember MS Windows uses Prefetch. It records into a database which files are needed at boottime. A fresh windows installation boots slower than a system that boots for the twentieth time. Prefetch makes sure the harddrive is used very very effectivly at OS bootup. This is hard to equal in GNU/Linux.

What do you think?

[JimmyW]

Cewl.

Remember MS Windows uses Prefetch. It records into a database which files are needed at boottime. A fresh windows installation boots slower than a system that boots for the twentieth time. Prefetch makes sure the harddrive is used very very effectivly at OS bootup. This is hard to equal in GNU/Linux.

What do you think?

I have been thinking about this too, but this need som deep kernel changes, or even rewriting part of the filsystem source i think..

I do plan to let initng sens what files a processes uses on startup, and on next boot preload the files from disk to memory cache, before the dependcy for the app is up, this will improve some... I am currently working on this...

[irondog]

I have been thinking about this too, but this need som deep kernel changes, or even rewriting part of the filsystem source i think..

I do plan to let initng sens what files a processes uses on startup, and on next boot preload the files from disk to memory cache, before the dependcy for the app is up, this will improve some... I am currently working on this...

This must be impossible without kernel hacks. The only 'program' that can record which files are opened, is the kernel.

[JimmyW]

This must be impossible without kernel hacks. The only 'program' that can record which files are opened, is the kernel.

Not imposible, youst hard..

I am thinking of preloding a monitor, or a wrapper to calls dlopen, fopen, and so on, in a library.
When a process that the init process has no data about is started, it will start with enviroment LD_PRELOAD set, and the library will call
all file openings directly to the initsystem... this works good in theory... Lets se if it works....

[i92guboj]

Ok, i said tomorrow but could not wait.

I tested and it seems to work, I have to polish it a bit still. The main issue is that initng complains about not being able to access /var/initng/in and /var/initng/out.

Also, is there any doc file that I can reffer to? I searched but did not find, i will look further, but now yes, tomorrow.¡!

[JimmyW]

Ok, i said tomorrow but could not wait.

I tested and it seems to work, I have to polish it a bit still. The main issue is that initng complains about not being able to access /var/initng/in and /var/initng/out.

Also, is there any doc file that I can reffer to? I searched but did not find, i will look further, but now yes, tomorrow.¡!

There is som missing fifos, type make mkfifos in source dir.

The only docs that exist is in /doc dir in the tarball, can you please help me writing som documentation?

[irondog]

This must be impossible without kernel hacks. The only 'program' that can record which files are opened, is the kernel.

Not imposible, youst hard..

I am thinking of preloding a monitor, or a wrapper to calls dlopen, fopen, and so on, in a library.
When a process that the init process has no data about is started, it will start with enviroment LD_PRELOAD set, and the library will call
all file openings directly to the initsystem... this works good in theory... Lets se if it works....

But init isn't a library, it doesn't provide fopen and friends. If you're not hacking the kernel, you need to hack libc. I have to get some sleep, but I don't think init is the right place to introduce Preloading.

Never mind, I'be be trying your new code soon and would be very pleased to see if someone is able to cleanly implement prefetch into GNU/Linux.

[JimmyW]

This must be impossible without kernel hacks. The only 'program' that can record which files are opened, is the kernel.

Not imposible, youst hard..

I am thinking of preloding a monitor, or a wrapper to calls dlopen, fopen, and so on, in a library.
When a process that the init process has no data about is started, it will start with enviroment LD_PRELOAD set, and the library will call
all file openings directly to the initsystem... this works good in theory... Lets se if it works....

But init isn't a library, it doesn't provide fopen and friends. If you're not hacking the kernel, you need to hack libc. I have to get some sleep, but I don't think init is the right place to introduce Preloading.

Never mind, I'be be trying your new code soon and would be very pleased to see if someone is able to cleanly implement prefetch into GNU/Linux.

The role of initng is on boot time, when it preload files listed in a db file, if that service is market starting, this is done in a fork or thread. Collecting tha data to the db, is done by the client-preloaded-lib by him self, or a client-lib and a collect-daemon. Watch the wery good example of sandbox in portage if you dont understand how this works with LD_PRELOAD...

[irondog]

[...]or even rewriting part of the filsystem source i think..

Prefetch in MS Windows also places files to preload very close to each other (fysical) on the disk/filesystem. There will never be a Linux develloper wanting to implement this into a new kind of filesystem. It's a little dirty idea, but when well implemented users benefit from it.
I'm not talking to implement such a filesytem for linux, but the idea of Microsoft to preload files might be a very good thing for Linux to boot faster.

I think most of the performance gain comes from preloading files into memory instead of the 'defragging' of files that are needed to boot the OS. Linux could use this and it might not be too hard to develop it cleanly.

The role of initng is on boot time, when it preload files listed in a db file, if that service is market starting, this is done in a fork or thread.

I agree init is the preloader. But main difficulty is the recording of the files to the database.

Collecting tha data to the db, is done by the client-preloaded-lib by him self, or a client-lib and a collect-daemon. Watch the wery good example of sandbox in portage if you dont understand how this works with LD_PRELOAD...

You mean overloading fopen() with a wrapper for all programs? Is that possible? I'm new to LD_PRELOAD

To continue about preloading: Have you ever seen the difference in speed of launching KDE after a CTRL+ALT+BACKSPACE and the first time KDE is lauched? Have you ever looked how ineffectivly the harddisk is used when booting? If we could just cat all files needed at bootup to /dev/null we would already have a 30% faster bootup on starting the desktop software. Not even talking about all system services.

[JimmyW]

[...]or even rewriting part of the filsystem source i think..

Prefetch in MS Windows also places files to preload very close to each other (fysical) on the disk/filesystem. There will never be a Linux develloper wanting to implement this into a new kind of filesystem. It's a little dirty idea, but when well implemented users benefit from it.
I'm not talking to implement such a filesytem for linux, but the idea of Microsoft to preload files might be a very good thing for Linux to boot faster.

I think most of the performance gain comes from preloading files into memory instead of the 'defragging' of files that are needed to boot the OS. Linux could use this and it might not be too hard to develop it cleanly.

The role of initng is on boot time, when it preload files listed in a db file, if that service is market starting, this is done in a fork or thread.

I agree init is the preloader. But main difficulty is the recording of the files to the database.

Collecting tha data to the db, is done by the client-preloaded-lib by him self, or a client-lib and a collect-daemon. Watch the wery good example of sandbox in portage if you dont understand how this works with LD_PRELOAD...

You mean overloading fopen() with a wrapper for all programs? Is that possible? I'm new to LD_PRELOAD

To continue about preloading: Have you ever seen the difference in speed of launching KDE after a CTRL+ALT+BACKSPACE and the first time KDE is lauched? Have you ever looked how ineffectivly the harddisk is used when booting? If we could just cat all files needed at bootup to /dev/null we would already have a 30% faster bootup on starting the desktop software. Not even talking about all system services.

I know that defraing the filesystem, and load all files at once have real bennefit, but the system with sysvinit and friends today, dont even use the harddrive 50% on boot time, for example, while modprobing modules, or probing an dhcp adress, the hardrive stands right still, that is not hapening, whit initng, not ever, until every file needed this boot is cached, tha harddrive will work..

Initng will also make sure that the daemon, or script will be ececuted exakty when all dependencys is met, and all in parrallall.

if you want to se this grapihicaly, youst wath som charts at http://www.bootchart.org..

Another thing to realy improve boot time is to make sure that you use prelinking, and cron it to prelink unprelinkt files on a regluar basis, prelink "defrags" all symbols in the ELF file format, locating library and symbol dependencys and caches this nto the binary.

the problem with defraging and reorganizing on a monted filesystem, needs kernel support, first a layer of online defraging, moving files physicaly on a mounted filesystem, than all underlaying filesystems have to support this, better wout be to let the kernel find an goot algorithm, that trys to detect what files generaly is loaded after a file, and defrag this automaticly, this wout benefit not only in boottime, but on every other application..

There is also an standard named TCQ, Tagged Comand Quening, all querys to the harddrive is sent asyncronysly and the hardrive himself, will load files in best order, he nows whats closest physicaly on the disk, i dont think linux kernel has support for this yet, ther was some realy buggy drivers in the 2.4 kernel, maby this is standard in 2.6...

Another way to boot realy fast is to use software suspend, then you dont need to think about defraging.

/Jimmy

[Tiger683]

How about doing the preloading through an initramfs.

You could log all the needed files, and crate the initramfs with them in it at shutdown, so that all the changes done
during the session are in it.

Just a basic idea......

T

[JimmyW]

How about doing the preloading through an initramfs.

You could log all the needed files, and crate the initramfs with them in it at shutdown, so that all the changes done
during the session are in it.

Just a basic idea......

T

How to tell all applications to first look for files in the initramfs, if not found look in the default filesystem in a smart general way?

I been loking around and found something named cachefs, cachefs is designed for network filesystems, cachefs uses a local partition on the desktop-machine to save cache that is used mutch on the nfs mount.

Insted, use cachefs, on the local root partition, and point the cache partition to a loopback image on hardrive, that loopback file is preloaded full every boot. i think cachefs is in the mm-sources..

[irondog]

Initng will also make sure that the daemon, or script will be ececuted exakty when all dependencys is met, and all in parrallall.

IMHO this is useless as bootup is nothing more than one single script that is executed. This script can launch programs to run in paralell, but fact is: system bootup still is one single script.

I agree that thins like modprobe and dhcpcd stop the harddisk doing things because the system is waiting. This is exactly why we would want a preloader to run in the background as one of the first things the rc-scripts activate. NEVER LET THE HARDDISK DO NOTHING!! Such a preloader doesn't yet exsit. No GNU/Linux distribution with graphical userinterface boots efficiently, I think not even with INITng.

How about doing the preloading through an initramfs.

You could log all the needed files, and crate the initramfs with them in it at shutdown, so that all the changes done
during the session are in it.

Just a basic idea......

T

That's silly. It would result into a huge kernel image and move all loading into the bootloader. Besides initramfs and initrd have their own libc (Klibc and Glibcstatic or dietlibc) and don't have anything to do with preloading things on the disk.

And what is the benefit if startup is faster on the cost of a slower shutdown?

[JimmyW]

IMHO this is useless as bootup is nothing more than one single script that is executed. This script can launch programs to run in paralell, but fact is: system bootup still is one single script.

But there is no sane parralell execution in the sysvinit, in inittng every litlle dependncy, mount, daemonstart, pidset... is a new dependecy set, this way it is easy and possible to make a model that newer stops, and start sleeping.

I agree that thins like modprobe and dhcpcd stop the harddisk doing things because the system is waiting. This is exactly why we would want a preloader to run in the background as one of the first things the rc-scripts activate. NEVER LET THE HARDDISK DO NOTHING!! Such a preloader doesn't yet exsit. No GNU/Linux distribution with graphical userinterface boots efficiently, I think not even with INITng.

The preloader, that is been written to ass we argument, is a fork or thread, to initng, that will preload files, in the best order, becous initng know in witch order services will start, and files will be requested, at the same time system boots up, and the first services is executed, this makes the harddrive NEVER SLEEP.

If you look on the boot-chart on http://jw.dyndns.org/initng can you se that right now my hardrive NEVER SLEEP, you can compere with the bootchart for default gentoo i provided on the same page.

That's silly. It would result into a huge kernel image and move all loading into the bootloader. Besides initramfs and initrd have their own libc (Klibc and Glibcstatic or dietlibc) and don't have anything to do with preloading things on the disk.

And what is the benefit if startup is faster on the cost of a slower shutdown?

Thats a ugly hack, on disk block ordering have to be commonly done, in an generic way in the kernel-filsystem code, i am not the person to write that code. but i realy want to see it.

The NEED concept, is a feature of initng, there are many others!

System status, and acounting
Realtime start status in %

Respawning of processes thats hang or quit, this can be done by sysvinit but not on the script init used bu gentoo (/etc/init.d/*)
and some more features right now, and many more are comming, look at the TODO list.

Watch my boot chart, or better test my init and you will se wath i meen.

/Jimmy.

[irondog]

The preloader, that is been written to ass we argument, is a fork or thread, to initng, that will preload files, in the best order, becous initng know in witch order services will start, and files will be requested, at the same time system boots up, and the first services is executed, this makes the harddrive NEVER SLEEP.

But the chart shows something that isn't gentoo's baselayout. I could also write an /sbin/init that never makes my harddisk sleep. I would rather have a /sbin/init that is able to launch any GNU/Linux distro (like sysvinit). I think you are comparing apples and pears.

Nevertheless, with the LD_PRELOAD trick is it possible to unset the fopen wrapper once the system has succesfully booted?
We could hook fopen() for every app to a recording engine to make a list of files needed at boottime. But is it possible to unset LD_PRELOAD again so we could remove the bloat of our so-called "preload-recorder".

[JimmyW]

The preloader, that is been written to ass we argument, is a fork or thread, to initng, that will preload files, in the best order, becous initng know in witch order services will start, and files will be requested, at the same time system boots up, and the first services is executed, this makes the harddrive NEVER SLEEP.

But the chart shows something that isn't gentoo's baselayout. I could also write an /sbin/init that never makes my harddisk sleep. I would rather have a /sbin/init that is able to launch any GNU/Linux distro (like sysvinit). I think you are comparing apples and pears.

What say that initng cant boot every linux distro?, sysvinit togehter with distrospecific init scripts dont support the need concept: look at http://www.atnf.csiro.au/people/rgooch/ ... t-scripts/ maby thats explain to you.

Nevertheless, with the LD_PRELOAD trick is it possible to unset the fopen wrapper once the system has succesfully booted?
We could hook fopen() for every app to a recording engine to make a list of files needed at boottime. But is it possible to unset LD_PRELOAD again so we could remove the bloat of our so-called "preload-recorder".

The library is always loaded, but the library preloaded can be writted to only report files about 1 minute from uptime.

Initng will only launch with LD_PRELOAD set when there is a service that it dont have any data on. so it will only suffer firts time starting an servivice on a computer.

[Tiger683]

Hey, back to the initramfs idea:
the creation of an image and packing it into initramfs should not be problem. now about telling the
apps what to load: you dont have to.
First, you could , in the linuxrc, dd the image into, say, /dev/ramX
(X=1,2,whatever), then mount /dev/ramX over the filesystem with unionfs, so apps would never notice they actually load stuff from ram. the
init itself could be started from there as well. then, at the end, just start a not overloaded daemon/app from the hd
which simply
umounts unionfs, clears /dev/ramX and dies. since the files in ram were mounted OVER those on hd, you never
have to tell anything to switch to hd, for them, they were doing it from hd already

T

[JimmyW]

Hey, back to the initramfs idea:
the creation of an image and packing it into initramfs should not be problem. now about telling the
apps what to load: you dont have to.
First, you could , in the linuxrc, dd the image into, say, /dev/ramX
(X=1,2,whatever), then mount /dev/ramX over the filesystem with unionfs, so apps would never notice they actually load stuff from ram. the
init itself could be started from there as well. then, at the end, just start a not overloaded daemon/app from the hd
which simply
umounts unionfs, clears /dev/ramX and dies. since the files in ram were mounted OVER those on hd, you never
have to tell anything to switch hd, for them, they were doing it from hd already

T

unionfs, never heard abount this, this sounds good, vill check it out, i am going to work now, i be back on this forum in about 7 to 10 hours.

Why use /dev/ram, basicy usin a loop on a local disk image woud be better, the disk image coud be preloaded by a simple cat disk.image > /dev/null in boot...

I realy likes this.... Have fun... / Jimmy Wennlund

[Tiger683]

hehe, because with it this way we only have the overhead of reading the image and packing it to ram, where it then resides all the time.
the whole process then works from ram, though thanks to unionfs EVERYTHING thinks they actually operate from hd.... its this way to have a DEVICE, which then gets MOUNTED onto/over the local filesystem overloading the hd-resident files __seamlessly__. so, basically, it gets you the performance of operating from ram without going away from the real_root layout, actually working with it the whole init-process long: scripts, modules, daemon-apps, whatever, and though you can do it selectively by only providing what you need in the image, that without even having to do any further actions, if its in the image, it gets loaded from ram, if not, it gets loaded from hd, both are vitrually equal to every other component of the process, it simply provides only what you pack into the image.

T

[irondog]

What say that initng cant boot every linux distro?, sysvinit togehter with distrospecific init scripts dont support the need concept: look at http://www.atnf.csiro.au/people/rgooch/ ... t-scripts/ maby thats explain to you.

I said: seeing the graphs of initng you are booting something that doesn't look like you are booting Gentoo. So, you are comparing apples with pears. Besides I'm saying, no matter how good initng works, I can create rc-scripts that make my harddrive go crazy, while starting other programs meanwhile. Paralell stuf can also be included into scripts leaving init the way it is in sysVinit.

About unionfs: sounds cool. Remember linux is very good at caching files into memory. Even if we would cat all files we need to /dev/null we already have a basic proof of concept of Prefetch in GNU/Linux. Just cat a 10mb file to /dev/null twice. You'll see it's faster the second time. In the long run this is nothing more than a stupid hack and maybe something like Unionfs is more like a final solution.

But one question is still unanswered: Can we unset LD_PRELOAD once programs are started with it?? Do we want all programs to run with LD_PRELOAD set? Is this a big performance leak once the system is up-and-running?

[krejler]

Very interesting, I'll have to try it out some time.

[Tiger683]

unanswered: Can we unset LD_PRELOAD once programs are started with it?? Do we want all programs to run with LD_PRELOAD set? Is this a big performance leak once the system is up-and-running?

IMHO the only thing we _must_ do is record which files were needed during the last boot. A db.
NOTE: with linuxrc i mean the initng-equivalent.
This is how i imagine the whole thing:
1) We boot the system for the first time: image is empty, everything runs from hd because /dev/ramX was empty nothing was loaded from ram.
2) we recorded all files initng utilized into, say, /etc/initng/ramfs_db
3) on shutdown, we stuff these into a simple dd-like-image and this into a initramfs with our linuxrc.
4) next time we boot, linuxrc, as, usually, does a dd if=$our_image of=/dev/ramX etc.
Then it mounts the /dev/ramX over the normal root partition with unionfs and duplicate resolution=overload.
5) from here it all runs normally until we reached end of init,
then we just start a script from hd which simply umounts unionfs-mounted /dev/ramX and empties it.
all done.

no fiddling with glibc/kernel internals needed.

cheers,

T

[irondog]

unanswered: Can we unset LD_PRELOAD once programs are started with it?? Do we want all programs to run with LD_PRELOAD set? Is this a big performance leak once the system is up-and-running?

IMHO the only thing we _must_ do is record which files were needed during the last boot. A db.

Yes, but would the last 10 boots be even more interesting? We can learn things out of the statistics of every time we boot.

NOTE: with linuxrc i mean the initng-equivalent.
This is how i imagine the whole thing:
1) We boot the system for the first time: image is empty, everything runs from hd because /dev/ramX was empty nothing was loaded from ram.
2) we recorded all files initng utilized into, say, /etc/initng/ramfs_db
3) on shutdown, we stuff these into a simple dd-like-image and this into a initramfs with our linuxrc.
4) next time we boot, linuxrc, as, usually, does a dd if=$our_image of=/dev/ramX etc.
Then it mounts the /dev/ramX over the normal root partition with unionfs and duplicate resolution=overload.
5) from here it all runs normally until we reached end of init,
then we just start a script from hd which simply umounts unionfs-mounted /dev/ramX and empties it.
all done.

no fiddling with glibc/kernel internals needed.

cheers,

T

HMn. Right. But this slows down our shutdown time. Besides, we want the harddisk to be active, but it's also very important not to waste CPU cycles because we are waiting on IO. It must be paralell with the normal bootup processes.