What's the benefit of compiling kernel modules into the kernel (instead of as loadable modules)?
It depends. If you have a small amount of memory, the use of modules may improve the resume as they are not reloaded every time (I found it significant on 2 GiB of RAM but not on 4 GiB on traditional harddrives). This is especially true when due to some bug in the battery module (regardless of being compiled-in or as module), it took very long to start (several minutes). Even without bug on gentoo I managed to shorten time (reported by
systemd-analysis) from 33s to 18s just by changing from statically compiled kernel to modules - 'surprisingly' the start of kernel changed from 9s to 1.5s.
Also, when you don't know what hardware are you going to use, modules are clearly beneficial.
PS. You can compile even vital drivers as modules as long as you include them in initrd. For example, distros will include the filesystem of /, drivers of harddrive etc. in initrd on installation.
As far as I know, there is no speed difference.
I think you will gain a few kB of kernel memory as the granularity of allocations is one page, so on typical architecture each module wastes an average of about 2kB (½ page) per would-be module. Even on embedded systems, that's hardly significant. You also gain a little disk space as the modules can be compressed in the same go as the kernel; that can be more relevant in embedded systems with little storage.
If you can dispense with modules altogether, you save a little kernel memory (no need for the module loader), disk space (no need for the module utilities), and system complexity (no need to include module loading as a feature in your distribution). These points are quite attractive in some embedded designs where the hardware is not extensible.
A couple potential benefits. Performance is an arguable one. You'd avoid some runtime overhead associated with a dynamic loader, but I doubt that's a big deal unless you're depending on a real-time scheduler.
If you're taking advantage of large pages on your system, then perhaps creating a larger static kernel image means you make more efficient use of the page descriptor cache. Some systems will 'cage' the kernel so that it packs tightly into one memory locality, which can alleviate some amount of delay due to minor, and possibly major, page faults.
It might suit you, architecturally, to deliver One Big Image, arguing that fewer independent modules is easier to maintain and the loss of flexibility is not important. A lot of this kind of reasoning ventures into matters of style and practice.
Sometimes it's necessary. If you compile some vital driver (e.g. SCSI driver) as a module your system won't boot.
Another great candidate for not compiling as a module is the filesystem type of the root partition. If the kernel doesn't understand
ext3 to read
/lib/modules/ how will it load modules from it ?
Think about it this way: to use modules the kernel needs to know enough about your system to to read and load kernel modules. Use that and trial and error :-)
I statically compile every driver for built-in hardware inside the kernel. Exception would be hardware which is not permanent (usb connected hardware, for example).
As my hardware configuration is not likely to change anytime soon, I don't bother with modules.