Date: Sat, 11 Jun 2011 23:17:03 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Adrian Chadd <adrian@freebsd.org>, Doug Barton <dougb@freebsd.org>, freebsd-arch@freebsd.org Subject: Re: [RFC] shipping kernels with default modules? Message-ID: <20110611201703.GO48734@deviant.kiev.zoral.com.ua> In-Reply-To: <D76B9160-327F-454F-AAD2-567D837BCD68@bsdimp.com> References: <BANLkTin2AwKRT7N6HWqBctJcT72_mR=Otg@mail.gmail.com> <4DF3B532.6020908@FreeBSD.org> <D76B9160-327F-454F-AAD2-567D837BCD68@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On Sat, Jun 11, 2011 at 02:00:20PM -0600, Warner Losh wrote: > > On Jun 11, 2011, at 12:34 PM, Doug Barton wrote: > > On 6/11/2011 2:21 AM, Adrian Chadd wrote: > >> Hi guys, > >> > >> Has there been any further thought as of late about shipping kernels > >> with modules only by default, rather than monolithic kernels? > >> > >> I tried this experiment a couple years ago and besides a little > >> trickery with ACPI module loading, it worked out fine. > >> > >> Is there any reason we aren't doing this at the moment? Eg by having a > >> default loader modules list populated from the kernel config file? > > > > Has anyone benchmarked monolithic vs. modular? I think that should be done before we move in this direction. > > I haven't noticed a difference, but I haven't done any specific benchmarking. There might be some measurable difference on i386, where we use dso for modules. As a consequence, the overhead of GOT/PLT indirection, and, more important, stolen %ebx on the register-starved architecture, may make a difference. I doubt that any difference can be measured on amd64. [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk3zzT8ACgkQC3+MBN1Mb4jOPQCfV62nloWb6iVteeZ5dGfMLLPJ BkoAn2hGp2Z6Qg6XxRbHa/I5Bzj6X8a3 =jA/5 -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110611201703.GO48734>