2015-08-25 14:42 GMT+02:00 Denys Vlasenko <[email protected]>: > On Tue, Aug 25, 2015 at 1:09 PM, Bartosz Golaszewski > <[email protected]> wrote: >> While working on an embedded system running several big services, X-org, >> fluxbox, Qt5 etc. where the boot-time was awful, it turned out that the >> readahead implementation from systemd (the one that was nuked in 2014) >> improves the time needed to start all the programs by a few seconds. >> >> This series introduces a small (LOC < 500) readahead daemon implementation >> based on fanotify and readahead syscalls. > > I am agonizing on this. > > I do believe that you see some improvement in your setup. > Possibly a substantial one. > > However. > > There is no "standard" readahead tool which is doing this, right? > > I usually accept patches to busybox tools which make them > more compatible with "standard" tools: I want to reduce > the frequency of cases where someone replaces a "standard" > tool with busybox equivalent on a working system and something > breaks. > > But if everything still works, it is just slow > (example: "find -exec ... {} +" does work, it is not optimized > compared to "find -exec ... {} ;"), this does not count as breakage.
I'm afraid I don't understand what you mean. Are you talking about standard tools being slower? > > Your readahead addition does not match either of these conditions. > It is not a copy of some standard tool, and if it is missing, things > don't break, they are just slower. The problem is: there is no standard readahead tool that could be copied. In Debian there are two separate readahead packages available: preload and readahead-fedora. Then there was the systemd one. They are all much more complicated than what I wrote. I tried creating something that would require zero maintenance. There's no standard to conform to. > How about this? > Let's accept (some of) the changes you need for your applet > to work, but you keep the applet per se out of the tree? > When a "standard" readahead tool appears in "big" distros, > we can return to this discussion. With today's usage of SSDs and systemd adoption I don't expect that to happen. Distros are not aimed at small boards with eMMCs, but at servers and desktops. I can't force you to accept the patch, but there are a lot of applets in busybox that are just random tools useful in embedded systems - inotifyd for example which I find very useful, has no standard counterpart. There's no bloat added by default since the daemon mode is disabled in Config. -- Best regards, Bartosz Golaszewski _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
