We need an init script wich loads ureadahead for fast boot. Reproducible: Always
Created attachment 218183 [details] sys-apps/ureadahead/ureadahead-0.100.0.ebuild courtesy of mantoo and tgR10 sys-apps/ureadahead/ureadahead-0.100.0.ebuild
Created attachment 218185 [details] sys-apps/ureadahead/files/ureadahead.rc
Created attachment 218187 [details] dev-libs/libnih/libnih-1.0.0.ebuild
i've attached the two ebuild posted on gentoo forum. don't forget to update sys-kernel/linux-headers to 2.6.30-r1 and sys-libs/glibc to 2.11-r1
(In reply to comment #2) > Created an attachment (id=218185) [details] > sys-apps/ureadahead/files/ureadahead.rc > I think I actually would see two of these, on early (that only needs root) and then one for localmount that passes external mount points onto the ureadahead command line (just like ubuntu does it). That would also need changes to the libnih ebuild (pass --disable-static and --libdir=/$(get_libdir) to the econf and remove *.la) and changes to the ureadahead ebuild (add --sbindir=/sbin). Also does ureadahead stop tracing when boot is done with your initscript?
Created attachment 224121 [details] updated ebuild Changes: * mores deps, some checks on the kernel config * binary in /sbin instead of /usr/bin * new init.d, as ureadahead act like a service not a daemon (it stop at end of boot) I opened a new bug for libnih (bug: 310093)
brublu, could you post also the ureadahead.initd file? thanks
Created attachment 224123 [details] new init.d script This script have only been tested with openrc. If you have a separate partition for /var, put it in boot runlevel, either you can try to run it in sysinit runlevel. I stop the tracing with a timeout (60sec), I tried to send a TERM signal at the end of the default runlevel with a script like: depend() { after '*' } start() { start-stop-daemon --stop --name ureadahead } But the boot time was worse (not enough data cached/wrong data cached).
(In reply to comment #8) > Created an attachment (id=224123) [details] > new init.d script > > This script have only been tested with openrc. > > If you have a separate partition for /var, put it in boot runlevel, either you > can try to run it in sysinit runlevel. > This does not handle if you have a /var/lib/ureadahead in your / and /usr is mounted from elsewhere. During boot you probably want files from /usr readahead also. I think two files (like ubuntus ureadahead and ureadahead-other) is the way to go, one reading files for /, and the other reading files from specified mountpoints. Also do ureadahead really readahead files from other mountpoint then / if you do not specify them (i.e. if you have /, /usr as two mountpoints and do not give ureadahead any options, will it read ahead both or just from /)?
Created attachment 224199 [details] init.d trying to follow Xake's advices Ok, now the init script have two phases: step 1: - run ureadahead without args so it read-ahead the root (/) - it may do tracing for all the system (force-tracing on cmdline, outdated packs files) step 2: - iterate all /var/lib/ureadahead/*.pack files and run ureadahead on it (this will read-ahead mountpoints: /home, /usr...) with only ureadahead in boot level (rc-update add ureadahead boot), the two phases are run after localmount in order. But, if you make a symlink like this: «ln -s ureadahead /etc/init.d/ureadahead.early» and add it to sysinit: «rc-update add ureadahead.early sysinit» then, the phases are split in the two runlevels: step1 in sysinit step2 in boot Well, as ureadahead can run with several modes (HDD, SDD, tracing, forced tracing, multiple mountpoints or not...), it's not easy to figure out all possibles paths. There can be bugs/race conditions if two processes (one tracing, one reading) work at the same time. Tested here with an HDD and only one mountpoint (/home)
(In reply to comment #10) > Tested here with an HDD and only one mountpoint (/home) Bruno, with your setup, does ureadahead decrease your boottime? Can you show some comparing times or even bootcharts?
Created attachment 227865 [details] profile for a normal boot Follow two bootcharts of my setup done after a fresh tracing. I modified bootchart to stop 30sec after X has started (instead of 5s), so I can see the start of xfce. I doesn't use any desktop manager but a script with su USER + startx. My HDD is a Maxtor 6Y080P0, YAR41BW0, max UDMA/133 (PATA) so not really fast (around 50MB/sec from hdparm), but with ureadahead, there is a peak at 45MB/s (instead of 20MB/s) By looking the end of CPU and Disk utilization, I have a boot of 59s for normal and 41s for ureadaread, so 18s wons ! We can see that ureadahead takes long time to run (~16s) so Xorg starts later (at 31 instead of 21) but the load of xfce is then really fast, so this is a global win. It would be interesting to see some bootcharts from a SSD setup.
Created attachment 227867 [details] profile for ureadahead
Which kernel options under kernel hacking / tracers are needed? In the message for ureadahead it says you need to activate Trace process context switches and events (ENABLE_DEFAULT_TRACERS) too, but that option isn't avaiable with gentoo-sources and zen-sources 2.6.33...
(In reply to comment #14) > Which kernel options under kernel hacking / tracers are needed? In the message > for ureadahead it says you need to activate Trace process context switches and > events (ENABLE_DEFAULT_TRACERS) too, but that option isn't avaiable with > gentoo-sources and zen-sources 2.6.33... Just search for it (use '/' in make menuconfig) because some options enable it (and makes it disapperes from menuconfig) so it is possible you have it enabled even if you cannot find it.
It works for me with kernel-2.6.34 and the mentioned patch. I have /var on a separate mountpoint (other mount points are /usr, /home, /boot). With ureadahead.early in sysinit I doesn't seem to work for me, but after I removed it and left only ureadahead in the boot runlevel ist works. Boot times are down from ~80 second to ~60 seconds into kde with a running firefox :-)
There's a problem the newest ebuild that was posted. When ureadahead installs it will create the /var/lib/ureadahead folder if it doesn't exist, but it fails to create a /var/lib/ureadahead/debugfs folder. This will cause ureadahead to spit out "ureadahead: Error while tracing: No such file or directory" for most users. The issue here is that ureadahead checks if debugfs is already mounted at /sys/kernel/debug, and if it's not it will attempt to mount it at /var/lib/ureadahead/debugfs. In my opinion ureadahead should always use the normal mount point of /sys/kernel/debug, but the author doesn't seem to agree. At least the fix is simple: mkdir /var/lib/ureadahead/debugfs This logic is also the cause of ureadahead.early failing for users with a seperate /var partition. Unless you have debugfs mounted very early it will attempt to mount one under the folder in /var, which doesn't exist yet. Fixing this is a bit more complicated, you need to change where ureadahead mounts debugfs when it doesn't find one already mounted by patching the source code as such: Alter line 78 of src/trace.c from #define PATH_DEBUGFS_TMP "/var/lib/ureadahead/debugfs" to: #define PATH_DEBUGFS_TMP "/sys/kernel/debug" Or even better, just remove line 78 and then change lines 138 and 141 to use PATH_DEBUGFS instead of PATH_DEBUGFS_TMP. Since this patch will also fix the missing directory problem, should the new ebuild patch the source code or just make the missing folder? I vote patch, but would like other opinions on the matter.
On my machine ureadahead was always erorring with: "ureadahead: Error while tracing: No such file or directory", even doing mkdir /var/lib/ureadahead/debugfs did not help. But the solution posted above: (> Alter line 78 of src/trace.c from > #define PATH_DEBUGFS_TMP "/var/lib/ureadahead/debugfs" > to: > #define PATH_DEBUGFS_TMP "/sys/kernel/debug" ) and applying the patch to the kernel have helped. The thing is that my bootchart clearly states that xfce is not read ahead. I do not use any graphical login manager like xdm/kdm. Is there a possibility to make ureadahead trace apps after boot process?
@gentaku from private message: To make bootchart run longer after the boot, I simply patched bootchartd like this: --- script/bootchartd 2005-11-13 18:40:01.000000000 +0100 +++ /sbin/bootchartd 2009-09-03 16:42:00.000000000 +0200 @@ -101,7 +101,7 @@ # Write the time (in jiffies). read uptime < /proc/uptime uptime=${uptime%% [0-9]*} - uptime=${uptime/./} + uptime=${uptime%%.*}${uptime##*.} echo $uptime # Log the command output @@ -127,7 +127,7 @@ while [ -f "$BOOTLOG_LOCK" ]; do if [ -n "$( pidof $exit_proc )" ]; then # Give the exit process some time to start - sleep 5 + sleep 30 # Flush the log files stop return @@ -247,7 +247,7 @@ killall -USR1 bootchartd ;; *) - echo $"Usage: $0 {init|start|stop}" + echo "Usage: $0 {init|start|stop}" ;; esac The sleep thing in wait_boot() is important. Looking in code, if you don't use any dm, i think you should be in initlevel 2 or 3 (from inittab) so bootchart will use exit_proc="mingetty agetty rungetty getty" to stop the log. @on debugfs problem: I've put "need sysfs" in the initscript so debugfs should be mounted on /sys/kernel/debug. Beware, my script is OpenRC only. The early script trick isn't for a /var separated and there is no checks when the script is run so it make the default script run badly after. More checks on this would be good. Eventually, months after, I fail to read my-self... maybe time to rework the logic in it ! ;-) Cheers.
(In reply to comment #19) Yes, yesterday I've managed to prolong bootchartd run time. With that I clearly saw that ureadahead didn't trace X server / xfce. And ls -sh /var/lib/ureadahead/ gives 4,0K debugfs 4,0K lib64.rc.init.d.pack 352K pack which is obviously too small to have X and xfce in it. Ureadahead should run longer - for it does on e.g. Ubuntu, but not here... I wonder why :>
(In reply to comment #20) > Yes, yesterday I've managed to prolong bootchartd run time. With that I clearly > saw that ureadahead didn't trace X server / xfce. And ls -sh > /var/lib/ureadahead/ > gives > 4,0K debugfs 4,0K lib64.rc.init.d.pack 352K pack > which is obviously too small to have X and xfce in it. with somthing like: ureadahead --dump <pack> | grep "^/" you can see what files are read by ureadahead > > Ureadahead should run longer - for it does on e.g. Ubuntu, > but not here... I wonder why :> > timeout is set by default to 60sec in /etc/init.d/ureadahead change this by putting: tracing_timeout=120... in /etc/conf.d/ureadahead (create it if need) Too, I think you can put a very long value and send TERM or INT to the process to stop it manually when you want.
Thank you very much! Now I see clearly that xfce had been traced after setting timeout to 120s. Now I would love if somebody helped me with interpretation of bootchart graph. The problem is I am very uncertain when system has stopped loading. I'm giving two charts, one with and one without ureadahead. Any help would be appreciated.
Created attachment 241757 [details] Bootchart with ureadahead in init process
Created attachment 241759 [details] Bootchart with NO ureadahead in init process
I'm trying to get ureadahead working and I keep getting >ureadahead: Error while tracing: No such file or directory I changed the debugfs directory in the source code and made the /var/lib/ureadahead folder but it still appears.
@for ALL please, give your configuration: - SSD/HDD - separat partitions /, /home, /var, /usr... - OpenRC ! This bug is for debugging the ebuild and his init script, feedbacks are welcome ! @gentaku looking your pics (swapped, it seems), I would look after the wicd service which delay the boot a little, maybe you can play with the /etc/rc.conf:rc_depend_strict option and/or rc_hotplug Try to start the network as late as possible (after X). (OT) Others rules are: * as many driver built-in in kernel. * avoid hot-plugged service by udev. look at http://lwn.net/Articles/299483/ and others google things... @jordan Can you check if you have debugfs mounted on /sys/kernel/debug/ if so, have you thoses files under it: ./tracing/available_events (grep for "fs:") ./tracing/available_tracers ./tracing/trace ./tracing/tracing_enabled ./tracing/events/fs ./tracing/events/fs/do_sys_open ./tracing/events/fs/uselib ./tracing/events/fs/open_exec Too, check write permission for /var/lib/ureadahead
(In reply to comment #26) > @jordan > > Can you check if you have debugfs mounted on /sys/kernel/debug/ > if so, have you thoses files under it: > > ./tracing/available_events (grep for "fs:") > ./tracing/available_tracers > ./tracing/trace > ./tracing/tracing_enabled > ./tracing/events/fs > ./tracing/events/fs/do_sys_open > ./tracing/events/fs/uselib > ./tracing/events/fs/open_exec > > Too, check write permission for /var/lib/ureadahead > I too get the error even after creating the debugfs directory (which imho should be created in the current ebuild, even if its a temporary fix). The tracing directory however does not have the "fs" subdirectory. I am currently applying the "optional" patch (which everyone seems to be applying regardless) to see if that fixes the problem.
