Ubuntu already improved their boot time
a-aa
a-aa at hollowtube.mine.nu
Thu Sep 1 00:18:41 UTC 2005
Erich Schubert wrote:
>Hi,
>
>
>>I use inotify (needing kernel 2.6.13), the advantage is I will catch
>>every file accessed in directories I monitor, the disadvantage is that
>>it takes some time to setup monitoring those dirs (need one open on all
>>directories, which causes some io wait).
>>
>>
>
>Have you considered using the audit interface? I used that to generate
>my readahead-files, actually. I had some race issues, but after some
>tweaking (and fixing of some related bugs in the kernel) it now worked
>okay.
>
>
No... but good idea, can you have multiple audit's monitoring at the
same time?
>I'm not sure if I needed a modified auditd. I think I used the unmodified one...
>The real big issue with audit is that someone might want to use it for
>something else... ;-) So I guess inotify is cleaner. But I'm not sure
>about it performance-wise: what will it do when I e.g. list
>/usr/share/doc ? or even when the updatedb cronjob kicks in?
>Monitoring via /proc might skip these "fast" accesses.
>
>
With inotify, you'll need to list which directories to monitor, but if
that's setup to be everything in /lib /usr/bin /bin and so on, that
catches pretty much everything you want to catch. And not skipping
those "fast" accesses was a goal, I made one plugin scanning using
/proc, and even when scanning many times a second and on many boots that
never caught stuff like sed/bash and their respective libraries. And
when doing readahead as early in the boot as possible, those are important.
>btw, here is my auditd start script:
>---....
>---
>
>Basically this sets up a ramdisk and monitors all "open" and "execve"
>calls. After all daemons have been started and some extra time has
>passed I kill auditd and disable the notifications again.
>Then some grep and filter magic to get the real readahead lists.
>
>Btw: someone suggested that readahead-list could use a \0-separated
>list of filenames instead of a newline separated list. While the code
>for the first case would indeed get easier (and eventually bring down
>readahead-list below the 1k mark) and faster (no memcpy needed any
>more), I think that doesn't outweigh the drawbacks in generating the
>readahead file. comments?
>
>
Use a memory mapped file when scanning, I find that practical when
parsing simple files anyway.
>best regards,
>Erich Schubert
>--
> erich@(mucl.de|debian.org) -- GPG Key ID: 4B3A135C (o_
> To understand recursion you first need to understand recursion. //\
> Wo befreundete Wege zusammenlaufen, da sieht die ganze Welt für V_/_
> eine Stunde wie eine Heimat aus. --- Herrmann Hesse
>
>_______________________________________________
>initscripts-ng-devel mailing list
>initscripts-ng-devel at lists.alioth.debian.org
>http://lists.alioth.debian.org/mailman/listinfo/initscripts-ng-devel
>
>
>
More information about the initscripts-ng-devel
mailing list