Re: module-init-tools v3.6 released
On Thu, 2009-02-05 at 11:56 +0100, Phil Knirsch wrote: Jon Masters wrote: This works fine, but means that, if we upgrade module-init-tools and there is a binary format change, then the system will be slow booting before depmod has been re-run again. I'm thinking about just doing a depmod -a on upgrade in such cases in the future...is there a problem with that idea? Imho in case of an update of module-init-tools that sounds absolutely reasonable. Users are much more likely to reboot their machines then get updates for module-init-tools, so the little overhead introduced with running depmod -a during an update should in general be significantly lower than the gains in subsequent bootups. Interestingly, I was expecting a lot more oh nos! Don't do that because it breaks some weirdly random preconceived notion but for once, nothing. Cool. Jon. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: module-init-tools v3.6 released
Jon Masters (j...@redhat.com) said: This works fine, but means that, if we upgrade module-init-tools and there is a binary format change, then the system will be slow booting before depmod has been re-run again. I'm thinking about just doing a depmod -a on upgrade in such cases in the future...is there a problem with that idea? Given the (presumable) infreqeuency of file format updates, especially compared to kernel updates, I wouldn't necessarily bother with it. Bill ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: module-init-tools v3.6 released
On Thu, 2009-02-05 at 09:52 -0500, Bill Nottingham wrote: Jon Masters (j...@redhat.com) said: This works fine, but means that, if we upgrade module-init-tools and there is a binary format change, then the system will be slow booting before depmod has been re-run again. I'm thinking about just doing a depmod -a on upgrade in such cases in the future...is there a problem with that idea? Given the (presumable) infreqeuency of file format updates, especially compared to kernel updates, I wouldn't necessarily bother with it. Neither would I, but the difference in boot time is fairly dramatic and people might whine ;) Jon. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: module-init-tools v3.6 released
Jon Masters wrote: On Wed, 2009-02-04 at 18:19 -0500, Jon Masters wrote: On Wed, 2009-02-04 at 03:47 -0500, Jon Masters wrote: I'm considering pushing an update to F-9 since v3.5+ is so much faster than previous releases - and it impacts boot time, but I have to admit that I was more concerned about F10 and rawhide until now. Oh, there's a slight issue with the handling of modules.order still for the binary tries in newer module-init-tools. This might manifest in a switch of e.g. module used in initrd for storage devices with multiple modaliases. So...one question... We now have binary versions of files like modules.dep, modules.alias and modules.symbols. These end in .bin and *augment* but do not replace the textual versions of these files. If we find the binary files, we are *much* faster at loading modules - boot overhead is e.g. under one second. But we need to be able to make changes to these binary files in order to add ordering support, and also just for the future. Our plan is to freeze the old text file format (the last change will be the one made recently in which modules.dep can now have relative paths to save space) and to fallback to it whenever the binary format changes and modprobe finds older binary files. This works fine, but means that, if we upgrade module-init-tools and there is a binary format change, then the system will be slow booting before depmod has been re-run again. I'm thinking about just doing a depmod -a on upgrade in such cases in the future...is there a problem with that idea? Jon. Imho in case of an update of module-init-tools that sounds absolutely reasonable. Users are much more likely to reboot their machines then get updates for module-init-tools, so the little overhead introduced with running depmod -a during an update should in general be significantly lower than the gains in subsequent bootups. Jusy my $0.02. Regards, Phil -- Philipp Knirsch | Tel.: +49-711-96437-470 Team Lead Core Services | Fax.: +49-711-96437-111 Red Hat GmbH | Email: Phil Knirsch pknir...@redhat.com Hauptstaetterstr. 58 | Web: http://www.redhat.com/ D-70178 Stuttgart, Germany Motd: You're only jealous cos the little penguins are talking to me. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
Re: module-init-tools v3.6 released
On Wed, 2009-02-04 at 18:19 -0500, Jon Masters wrote: On Wed, 2009-02-04 at 03:47 -0500, Jon Masters wrote: I'm considering pushing an update to F-9 since v3.5+ is so much faster than previous releases - and it impacts boot time, but I have to admit that I was more concerned about F10 and rawhide until now. Oh, there's a slight issue with the handling of modules.order still for the binary tries in newer module-init-tools. This might manifest in a switch of e.g. module used in initrd for storage devices with multiple modaliases. So...one question... We now have binary versions of files like modules.dep, modules.alias and modules.symbols. These end in .bin and *augment* but do not replace the textual versions of these files. If we find the binary files, we are *much* faster at loading modules - boot overhead is e.g. under one second. But we need to be able to make changes to these binary files in order to add ordering support, and also just for the future. Our plan is to freeze the old text file format (the last change will be the one made recently in which modules.dep can now have relative paths to save space) and to fallback to it whenever the binary format changes and modprobe finds older binary files. This works fine, but means that, if we upgrade module-init-tools and there is a binary format change, then the system will be slow booting before depmod has been re-run again. I'm thinking about just doing a depmod -a on upgrade in such cases in the future...is there a problem with that idea? Jon. ___ Fedora-kernel-list mailing list Fedora-kernel-list@redhat.com https://www.redhat.com/mailman/listinfo/fedora-kernel-list
