>>No. Very few kernels have ever allowed themselves to be swapped out.
>Not true, kernels with pageable code are common. VMS and Windows NT
>have partially pageable kernels, for example; VMS was designed that
>way in the early 80s, so this is far from a new trick.
Two operating systems? I still say they are rare, but that's a
subjective evaluation. Maybe you're counting the number of copies
installed, not the number of different systems developed.
Quote:>>The problem with doing so is that the swapper or the page tables might
>>get paged out, making it quite difficult to page anything back in.
>Only if you don't do it right. The kernel has to be carefully separated
>into pageable and non-pageable portions, but this isn't that difficult.
>This is a foolish objection. It's not hard to identify those portions
>that must be locked in memory.
It may not be hard if the OS is designed from the ground up with that
in mind. I remember hearing of someone who was trying to swap out
parts of the OS, and in some rare cases actually swapped out
VM-critical pages. So while it can be done right, that doesn't make
it easy to do right. (If you do do it, don't you end up with
something similar to a microkernel: the vm-critical stuff acting like
the microkernel and the rest acting like a server. Sure they're in
the same address space, but that's been done with microkernels, too
(e.g. mk with the AD3 server)?)
Quote:>>While it is theoretically possible to isolate those portions of the
>>kernel that deal with paging and allow the rest of the kernel to be
>>swapped out, that usually isn't a good idea, both from a software
>>development standpoint and from a performance standpoint.
>I'm not sure I entirely agree. It is true that the folks that design
>pageable kernels also tend to write bloated kernels, because they've
>taken the pressure off of themselves, and this often leads to trouble
>(more kernel-level code == more security problems and OS crashes, because
>there's a lot more code to get right). But there is in principle no
>performance penalty for a paging kernel (since the only times you page
>is when the alternative is to page out part of the kernel or page out
>user tasks, so why be forced to keep around unused kernel code?).
It all depends on how it is done, but any added complexity in the
kernel has the potential to hamper performance. From the perspective
that pagability in the kernel would be rarely of benefit, but would
probably increase the code size and complexity, you've got a very good
chance that most of the time, your system would run slightly slower.
Quote:>>On a side note, one feature of a microkernel approach (e.g., GNU Hurd)
>>is that the traditional kernel services are broken up into the
>>microkernel and a bunch of servers. Only the microkernel and those
>>servers that handle paging (i.e., the default pager) need to be wired,
>>and the others are swappable.
>But as Linus will point out, there's a serious performance penalty to
>be paid for microkernels.
Especially if you're using Mach IPC. There are better models that
don't appear to be so bad. Not that I was making a performance
argument with regards to microkernels, though I do believe that a
well-designed microkernel can be fast (as do a good number of OS
researchers who are still developing new ones, myself included).
Quote:>>The closest Linux comes to this is with modules and kerneld. If a
>>module isn't used for a while, kerneld will unload it. I guess you
>>could think of that as swapping out portions of the kernel.
>Yes, it is exactly that. Similarly, 2.1.x now has support for discarding
>code used only at initialization (this code is one of the big things the
>pageable-kernel advocates point to). If you can discard unneeded
>initialization code and unneeded device drivers, and you keep the rest
>of the kernel small, the advantage of making the kernel pageable is
>small. But please don't look like an idiot when you argue against
>pageable kernels, and claiming that you might page out the page fault
>code, when people have been writing paging kernels for at least 15 years,
>just makes you look foolish.
Pagable kernels have an extra level of complexity, and hence, have
more potential for failure. Yes, that can be overcome, but most
operating systems don't bother. Yes, it has been done, but as you
point out, the benefit (given a well-designed system to begin with) is
minimal at best. Most of the operating systems community seems to
believe that pagable kernels are a bad idea (or at least not worth the
effort). As I see it, if you think your kernel needs to be pagable,
it's a good sign you have a lot of junk in there that shouldn't be in
there.
Quote:>>If you
>>need RT support, then you should probably avoid dynamically loading
>>modules with kerneld (load them at boot time explicitly if you want
>>them as modules).
>Um, you need more than this to get RT support. And even with kerneld
>and modules you can pre-load a module before starting some task.
No. In the context of worrying about the kernel swapping itself out
(which is the context for this thread), that is all you need for RT
support. And didn't I just point out that you can pre-load the
modules? Sure, you might want to do it at some time other than when
you boot (even have the application load them explicitly before it
needs RT, if you want; though that would probably not be portable).
You sure are argumentative today.
--PC
--
=== "My 'tomorrow' is pretty flexible." ===
=== --Bob Gray, Dartmouth CS grad student ===
by