2015-06-19 15:34 GMT+08:00 Chaiken, Alison <ali...@she-devel.com>: > cee1 <fykc...@gmail.com> writes: >> 3.1 "consider disabling readahead collection in the shipped devices, >> but leave readahead replay enabled." > > > ceel, are you aware that readahead is deprecated in systemd and has not been > included since about release 216? Some of us in automotive are still > working on it. I have some patches here > > https://github.com/chaiken/systemd-hacks/tree/packfilelist > > against 215 that add various features. We may soon be forward-porting > these, along with readahead itself, to the latest version. Glad to hear that :)
> >> The readahead doesn't work very well on my experiment, > > > I spent considerable time performing boot experiments on production > hardware, including trying different I/O schedulers. My conclusion was > that readahead provides benefits in boot-time only when large, monolithic > binaries start. If these gigantic applications were rearchitected to be > more modular and could load libraries dynamically when needed instead of all > at once, I suspect that the speedup associated with readahead would vanish. > Nonetheless, under the right conditions, readahead may speed up boot on real > hardware in product-relevant conditions. > > The problem is actually quite complex in the case of eMMC boot devices, > which have their own sophisticated embedded controllers. To properly > optimize the whole system, we need to know the behavior of that controller > and model what happens at boot in the full system using different Linux I/O > schedulers and readahead strategies. Unfortunately we don't have all that > information. My suspicion is that we might actually boot faster from raw > NAND flash, but then of course we have to perform our own wear-levelling and > block sparing. BTW, I wonder whether the F2FS helps, which seems very friendly to flash storage. > >> The replaying sequence: A, B, C >> The actual requesting sequence: C, B, A >> If we can figure out the requesting sequence, it can achieve real read >> "ahead"[1]. > > > I have verified in detail that readahead worked as intended: the degree to > which the system was I/O-bound did decrease, even in cases where there was > no net speedup. Any idea why? >> 4. Get rid of systemd-cgroups-agent. This requires introduction of a >> new kernel interface to get notifications for cgroups running empty, >> for example via fanotify() on cgroupfs. >> Is there any related work in processing? > > > Are you aware of "JoinControllers"? You appear to have old versions of > software, which doesn't garner much sympathy from developers. So this option can reduce the times of invoking systemd-cgroups-agent? Note the points list in my previous mail come from http://freedesktop.org/wiki/Software/systemd/Optimizations/ and https://wiki.tizen.org/wiki/Automotive_Fast_Boot_Optimization, they seems interesting to me. > >> These makes it hard to use systemd in a customized system. > > > The Linux services business benefits from churn in userspace code . . . Kernel scheduler of an analogy - there's no kernel scheduler specific for embedded device, nor a kernel scheduler specific for linux server, but a scheduler for all the cases. So it should do with systemd, right? >> What I call >> for is to make the cold boot logic "declarative", something like: >> main.c: >> log_to_A >> mount_X >> mount_Y > > > Good news: you are free to choose SysVInit. What I mean is the initialization stage of systemd, that's e.g. mounting the "API filesystem", etc. I expect a "declarative" expression of that, which will help to customization and debugging(without going deep to the code) > >> I wonder whether a property system also makes sense in systemd's world? > > > systemd unit files are already declarative lists of properties, right? The property system is something likes a system preference system(i.e. similar to a system dconf), IIRC, os x has a similar thing. My question is do we need a similar thing in systemd world, since systemd seems aiming to provide the basic infrastructure of a linux distribution? -- Regards, - cee1 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel