On Fri, Mar 18, 2011 at 14:40, Gustavo Sverzut Barbieri <barbi...@profusion.mobi> wrote: > On Fri, Mar 18, 2011 at 10:52 AM, Andrey Borzenkov <arvidj...@mail.ru> wrote: >> On Fri, Mar 18, 2011 at 12:35 PM, fykc...@gmail.com <fykc...@gmail.com> >> wrote:
>>> 1. What can readahead affect boot-time? >>> Sadly observed negative affect -- boot-time increases at least 1s. >> >> From subjective feelings (no real measurements) I confirm it. > > I noticed it as well, even with my Macbook Pro i7 with 8Gb RAM and > 128SSD using btrfs. It's ~0.5 sec faster here with readahead on a SSD. > But it could be improved yes. As you all said, maybe we should handle > udev hotplug in a more throttled way by postponing non-critical > devices and having everything else to be hotplug aware? That's not really possible, you can not really make such list, and you need to handle all parent devices from all 'interesting' devices anyway to expose them. The 'settle' service is only there for broken services. Originally it wasn't even pulled into the base target but was free-hanging with nobody getting blocked by it. Lennart pulled it in for a few broken things and selinux to work, and it ended up blocking the base target to be on the safe side for non-hotplug aware stuff. We might want to re-check if that's really what we want. Ideally, the entire 'settle' step would not even exist. I guess in your limited environments, you can just drop the entire thing and let the coldplug task run in the background. Services need to cope with uninitialized devices then, and filter them out when enumerating subsystems, and wait for the proper event from udev. That should all be pretty straight-forward if you don't need to support all the insanity in usual Linux distros. Kay _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
