Kernel swapping itself out ? (Real Time Support)

Kernel swapping itself out ? (Real Time Support)

Post by Preston F. Cr » Thu, 23 Oct 1997 04:00:00




>Is it possible that the Linux Kernel swaps parts of itself out
>sometimes ? This is kinda dangerous for real time purposes, I'd think
>since the whole system is stopping for a short moment when regaining
>those parts (especially because usually it got swapped out due to
>heavy system usage - so it takes pretty long to load it again).
>I don't know whether the kernel does this

No.  Very few kernels have ever allowed themselves to be swapped out.
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.
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.

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.

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.  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).  Of course, only the processes that need the
modulized kernel services would block when kerneld is trying to load
the modules, not the entire system.

--PC
--
Q:  How many Microsoft programmers does it take to upgrade a lightbulb?

 
 
 

Kernel swapping itself out ? (Real Time Support)

Post by Elliot L » Thu, 23 Oct 1997 04:00:00



Quote:>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.

The NT team was lead by a guy who worked on VMS, perhaps explaining the
similarity.

Quote:>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 isn't?

Let's see, to swap something back in you could potentially need:
        - swap code itself
        - device driver to access the device
        - filesystem driver if you're swapping to a file
        - all the other stuff like interrupt handlers and etc.
          that you will need to make the above stuff work...
        - scheduling code & data etc. for SMP machines

Note that the device driver & filesystem driver cannot be determined
statically; you'd need to determine them every time you swapon()/swapoff()

I'm no kernel guru, but figuring out exactly which pages are used for what
doesn't sound trivial to me.

(I'd be happy to be proven wrong, of course - if your mission in life is
to make the Linux kernel swappable, go ahead :-)

-- Elliot                                       http://www.redhat.com/
My trademark on the function 'main' is now being enforced; please fax a
ten dollar bill to me for this month's license fee.

 
 
 

Kernel swapping itself out ? (Real Time Support)

Post by Joe Bu » Thu, 23 Oct 1997 04:00:00



Quote:>>>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,

Please.  I give you two examples, and you think that is all that there
are?  Both of those examples were in their time highly successful (and, to
be fair, the same guy was behind both systems, though he denies that WNT
was chosen to be VMS + 1).  Remember that there simply haven't been that
many independently written OSes that handle virtual memory (almost all
Unix implementations are rewrites of the same two original versions).

Quote:>>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,

I'm assuming that it is done competently. :-)

Quote:>but any added complexity in the
>kernel has the potential to hamper performance.

There are circumstances when the alternative (no paging of the kernel)
gives worse performance: there isn't enough memory, so the version without
kernel paging swaps more.

Note that I am *not* advocating that Linux try to page the kernel.
I don't think it's worth it.  I'm just saying that arguing against
it on the basis that it's extremely difficult and complex is misguided.

--
-- Joe Buck     http://www.synopsys.com/pubs/research/people/jbuck.html
 If you thought flashing ads on Web sites were annoying, wait till the Web
 and your operating system are "seamlessly integrated" and watch the
 pulsating promotional crud spill out over your desktop.  -- Scott Rosenburg

 
 
 

Kernel swapping itself out ? (Real Time Support)

Post by Joe Pfeiffe » Thu, 23 Oct 1997 04:00:00



Quote:

> 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.

I have heard that this was true of the Manchester Atlas, the first
computer with VM.  The page replacement code could be swapped out.
--
Joseph J. Pfeiffer, Jr., Ph.D.       Phone -- (505) 646-1605
Department of Computer Science       FAX   -- (505) 646-1002
New Mexico State University          http://www.cs.nmsu.edu/~pfeiffer
 
 
 

Kernel swapping itself out ? (Real Time Support)

Post by Georg Grev » Thu, 23 Oct 1997 04:00:00


-----BEGIN PGP SIGNED MESSAGE-----

Hi !

Is it possible that the Linux Kernel swaps parts of itself out
sometimes ? This is kinda dangerous for real time purposes, I'd think
since the whole system is stopping for a short moment when regaining
those parts (especially because usually it got swapped out due to
heavy system usage - so it takes pretty long to load it again).

I don't know whether the kernel does this - I am just suspicious it
might do it and if it does I would like to suggest a "mlockkernel()"
system call or something of the like to make the kernel more stable
for real time processes if neccessary.

Later,
        Georg

- --

http://porter.desy.de/~greve/
"People who fight may lose. People who do not
fight have already lost." -- Bertold Brecht

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: cp850
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBNE3q6VZXgZXDxqJtAQGsAAP9E8KpYYPvVqGvqS24iNW/UXYSYucJnzjb
R82HeBHY/in7QKAa47yhQ1UKbiXW5XYX3gdp9h8yIJxk9tpaQ0zZljoFz2f6LsoZ
6LQIGeygOfvN8+bk4nEnefurZHr6ITreSvaH5bwZbYbRQLfSvtt0dbvJvqCja3lC
6IupOOLbhy4=
=yyzq
-----END PGP SIGNATURE-----

 
 
 

Kernel swapping itself out ? (Real Time Support)

Post by Przemek Klosowsk » Thu, 23 Oct 1997 04:00:00



> Is it possible that the Linux Kernel swaps parts of itself out
> sometimes ? This is kinda dangerous for real time purposes, I'd think

Linux kernel is non-swappable. Interestingly, the whole kernel is of a
similar size to the non-swappable part of NT kernel, which is a nice
thing to remind of an NT advocate who gloats too much.
--

                        NIST Center for Neutron Research (bldg. 235), E111
                        National Institute of Standards and Technology
                        Gaithersburg, MD 20899,      USA
                        .. and for spam extractors, FCC Commisioners' email is:

 
 
 

Kernel swapping itself out ? (Real Time Support)

Post by Joe Bu » Thu, 23 Oct 1997 04:00:00



Quote:>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.

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.

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?).

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.

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.

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.

--
-- Joe Buck     http://www.synopsys.com/pubs/research/people/jbuck.html
 If you thought flashing ads on Web sites were annoying, wait till the Web
 and your operating system are "seamlessly integrated" and watch the
 pulsating promotional crud spill out over your desktop.  -- Scott Rosenburg

 
 
 

Kernel swapping itself out ? (Real Time Support)

Post by Preston F. Cr » Thu, 23 Oct 1997 04:00:00




>>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    ===

 
 
 

Kernel swapping itself out ? (Real Time Support)

Post by Thomas Koen » Fri, 24 Oct 1997 04:00:00



Quote:>No.  Very few kernels have ever allowed themselves to be swapped out.
>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.

Being able to page out page tables is a big win (if you know how
to get them back :-).  Large processes can consume quite a lot of
memory otherwise, even if all they do is sleep on the swap.
--

Harrassing E-Mail may be posted.  If you don't like to see that, don't
send me E-Mail.
 
 
 

Kernel swapping itself out ? (Real Time Support)

Post by Dave Pla » Fri, 24 Oct 1997 04:00:00


Quote:>>Two operating systems?  I still say they are rare,

>Please.  I give you two examples, and you think that is all that there
>are?  Both of those examples were in their time highly successful (and, to
>be fair, the same guy was behind both systems, though he denies that WNT
>was chosen to be VMS + 1).

Another example, with an independent heritage, was the
BPM/BTM/CP-R/UTS/CP-V timesharing-and-batch operating systems written for
the Sigma and Xerox mainframes.

These operating systems consisted of a resident kernel, and a series
of swappable overlays which shared a single portion of the machine's
(relatively small) virtual address space.  The resident (root) overlay
was mapped 1:1 in memory - its code could be executed with the memory
map (virtual-to-physical) translator either enabled or disabled.  All
interrupt-level code was in the root area, as was the swapper/pager,
memory management, I/O system, and other fairly important stuff.

The operating system overlays contained code which was too big to fit
in the root, which didn't have to run with the MMU disabled (i.e. not
at interrupt time) and which could be swapped out if memory demands
made it necessary.  It was quite common to have several different
overlays in physical memory at one time; only one of them would be
memory-mapped into the overlay region of virtual memory.

Switching between overlays (either when switching tasks, or in order
to do a jump or subroutine call between overlays) required
intervention by the root-kernel code, since the hardware memory map
would need to be modified (at least) and the new overlay might have to
be swapped in.  This was quite easy for the programmer, though, as
there were a couple of utility routines (JMPOVR and JSROVR) to jump or
call between overlays.  Upon return from a JSROVR, the root kernel
would reverse the memory-map change before returning to the calling
overlay.

One variant of this OS architecture (CP-R) was specifically designed
to support realtime tasks.

Yes, doing this sort of swappable-kernel OS design requires some
careful thought and planning, and it's probably not the commonest
design you'll find today... but it can be, and has been done quite
successfully.

--
Dave Platt                                        Speaker-to-kernels

Visit the Jade Warrior home page:     http://iq.nc.com/jade-warrior/

 
 
 

Kernel swapping itself out ? (Real Time Support)

Post by Klaus-Georg Adam » Fri, 24 Oct 1997 04:00:00





> >>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.

AIX (at least up to 3.2.5e) has a preemptable, swappable kernel as
well.

-- kga
-------------------------------------------------------------------------

Institut f. Anorg. Chemie II                           Tel: 0721 608 3485
Uni Karlsruhe
-------------------------------------------------------------------------

 
 
 

Kernel swapping itself out ? (Real Time Support)

Post by James Youngma » Fri, 24 Oct 1997 04:00:00


  Preston> It may not be hard if the OS is designed from the ground up
  Preston> with that in mind.  I remember hearing of someone who was
  Preston> trying to swap out parts of the OS, and in some rare cases
  Preston> actually swapped out VM-critical pages.  
[snip...]

Swapping was retrofitted to the NT kernel, for example.

 
 
 

Kernel swapping itself out ? (Real Time Support)

Post by Victor A. Grinber » Fri, 24 Oct 1997 04:00:00




> ? Is it possible that the Linux Kernel swaps parts of itself out
> ? sometimes ? This is kinda dangerous for real time purposes, I'd think

> Linux kernel is non-swappable. Interestingly, the whole kernel is of a
> similar size to the non-swappable part of NT kernel, which is a nice
> thing to remind of an NT advocate who gloats too much.

NT advocate? I haven't seen any lately:)
 -vg
 
 
 

Kernel swapping itself out ? (Real Time Support)

Post by Thomas Koen » Fri, 24 Oct 1997 04:00:00


[X-post and F'up to comp.society.folklore]


Quote:>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.

AFAIK, the MVS kernel is also partially pagable, and that goes back
to the MVT systems of the seventies, when the /370 series was
introduced.

Can anybody supply more details? :-)
--

Harrassing E-Mail may be posted.  If you don't like to see that, don't
send me E-Mail.

 
 
 

1. Kernel Real Time Clock (RTC) Support for I2C Devices

I have been unable to find an answer for this in the LKML archives, so I
am hoping someone on this list might perhaps have some insight or pointers
thereto on this question.

I have an embedded board with a PowerPC 405GP on which Linux 2.4.2
(MontaVista's version thereof) is running swimmingly. Attached to that
PowerPC's I2C controller is a Dallas DS1307 I2C RTC.

From the looks of drivers/char/rtc.c it would appear that this kernel
driver only supports bus-attached RTCs such as the mentioned MC146818. Is
this correct?

What is the correct access method / kernel tie-in for supporting such an
I2C-based RTC device using the "standard" interfaces?

My hope is to use 'hwclock' from util-linux w/o modification. Is this
reasonable?

Thanks,

Grant Erickson

--
 Grant Erickson                       University of Minnesota Alumni

  o http://www.umn.edu/~erick205                          1998 MSEE

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

2. vmstat formatting patch

3. RPC time outs at boot time

4. Firewall Entries

5. Will the *Real* kernel version and revision reveal itself?

6. Program How to get text on Xwin~

7. CFP: AAAI/KDD/UAI-2002 Workshop - Real-Time Decision Support and Diagnosis

8. let binfmt_misc optionally preserve argv[1]

9. enhanced real time clock support; how to say 'y'

10. Real-time futexes (priority inheritance/protection /robust support) take 4

11. POSIX 1003.4 Real Time Support ?

12. Need Commercially Supported Embedded Real-Time BSD Services

13. Solaris Real-Time Support