Messages in this thread | | | Date | Mon, 8 Nov 1999 16:21:02 +0000 (GMT) | From | Riley Williams <> | Subject | Re: Modular vs. Monolithic kernel builds. |
| |
Hi Mike.
> I've built both modular (which I prefer) and monolithic kernels, > and I'm wondering how much benefit at all monolithic kernels > give and if they are even remotely worth bothering with.
In certain circumstances, yes they are.
> First off, I am aware of most of the advantages and > disadvantages of the two approaches, however I don't > particularly see any difference in the areas that are > interesting to me: Performance.
> As far as memory consumption is concerned, on a modern system > with 64Mb of RAM or higher - a monolithic kernel's increased > size is lost in the noise. A few hundred Kb of drivers built in > do not use up any significant amount of memory that is noticed, > not on my 96Mb system anyways.
> What additional overhead is there when a module gets called?
That varies from driver to driver, but with some drivers, there can be a LOT of extra overhead if the driver isn't already in memory.
As an example that I came across recently, take a kernel with the vfat driver compiled as a module and not currently loaded into memory. Add that the msdos driver is either not compiled at all (my preference) or is also compiled as a module and not loaded. Also put the following entry in /etc/fstab to allow non-root to mount a certain partition...
/dev/hdd4 /zip auto noauto,default,user
...and put a vfat disk in the zipdrive in question, and ensure the directory /zip actually exists.
Finally, put yourself in the seat of the user wishing to mount the said partition. They can't mount it, not because they don't have the necessary permissions (they have those) but because the vfat module isn't already in memory and with the above settings kmod never gets asked to load it.
In this specific case, the "extra overhead" consists of tracking down somebody with root privelidges who can log in and do the necessary insmod command to allow the above to work, always assuming that the user knows that such is what is required, that is.
Best wishes from Riley.
PS: The kernel versions page is now back online at the URL below, and includes separate sublists both for each kernel series, and for each year of development.
+----------------------------------------------------------------------+ | There is something frustrating about the quality and speed of Linux | | development, ie., the quality is too high and the speed is too high, | | in other words, I can implement this XXXX feature, but I bet someone | | else has already done so and is just about to release their patch. | +----------------------------------------------------------------------+ * http://www.memalpha.cx/Linux/Kernel/
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |