Very Computer

Hi there,

Okay, now if this is the kind of question where you've been thinking: "If
one more person asks...", then please have mercy on me.

I've been going over the _old_ documentation to the Kernel's memory
management and the related sources, as well as the exception handlers.
And still it isn't clear to me what the actual reason is why Kernel pages
are taboo w.r.t. paging?

Theoretically of course anything but the paging-code&page-fault can be paged
out (and since Kernel code is usually clean, it doesn't even need to be
swapped out as such, just reloaded). Is it just an issue of speed? If so,
I'd think that a cunningly efficient method could be devised to offer just
that extra little bit of physical memory at the minimum possible swapping
speed cost.

I know that I know nothing, so all explanations are welcome!

Thanks,
       Randal

_______________________________________________________________________
RANDAL A. KOENE
PhD2, Neural Modeling Lab, Department of Psychology - McGill University

_______________________________________________________________________

With a pageable kernel the kernel code could be interrupted at any time,
because the pagein code would have to sleep, to read a code page from the
hd. Some other process could steal resources from his back then.
This would most likely lead to data corruption and * deadlocks.
For example imagine, the harddisk driver is paged out and then the paging
code tries to read a page from the hd. Or if the pagein code itself is paged
out.

-Andi

 >For example imagine, the harddisk driver is paged out and then the paging
 >code tries to read a page from the hd. Or if the pagein code itself is paged
 >out.

 What about distinguishing two kinds of kernel code: pageable and
non-pageable.  The pageable functions could be marked using gcc's
__attribute__((__section__(".text.pageable"), just as it is currently
used with the initialization code.

 The paging code itself, and all low level halves of the block device
drivers, and interrupt handlers would be marked non pageable.  Almost
all other stuff could be pageable. Of course, race conditions would
still stay an issue, but didn't SMP face the same kinds of problems?

 >
 >-Andi

--
 Linux - Why use Windows, since there is a door?

 Alain

Quote:

> And still it isn't clear to me what the actual reason is why Kernel pages
> are taboo w.r.t. paging?

-wayne

--
Wayne Schlitt can not assert the truth of all statements in this
article and still be consistent.

Also large parts of the kernel aren't multithreaded yet, so it would
still be a lot of work. And to get this thing stable would probably be
a horror trip: you would have to look through all of the 1M+ lines
of kernel code.

-A.

Thanks for the info! Cheers,
                            Randal

_______________________________________________________________________
RANDAL A. KOENE
PhD2, Neural Modeling Lab, Department of Psychology - McGill University

_______________________________________________________________________

-Andi

Kristian

--
Kristian Koehntopp, Wassilystrasse 30, 24113 Kiel, +49 431 688897

--Tim Smith

 - Filesystem drivers - perhaps if you had lots of filesystems, or dos
   ones that you used seldomly.
 - A-Out binary support
 - Floppy disk block device
 - Mouse

The rest, net drivers, hard disk device drivers, and so on are likely to
be in use enough to negate any usefulness of swapping them out.  Besides
that, do you really want your ethernet drivers swapped out when packets
start coming in?  Most of what is in the kernel needs to be there, and it
needs to have quick access.

Now, lets look at what all the above that I mentioned have in common... they
are all configurable as loadable modules.  There are already provisions to
handle the automatic loading, and unloading of modules on a demand basis.

It's just not worth it.  The memory involved is too small, most of the
kernel is too vital.  That's /why/ it's in the kernel.  The less vital
stuff is either a module (see above), or a user program.

Quote:

> I don't know about you, but if I were working on it, I wouldn't bother
> worrying about paging out the kernel.  RAM is cheap, the the gain by

Quote:> swapping the kernel is, what, a few hundred K maybe.

Quote:> Now, lets look at what all the above that I mentioned have in common... they
> are all configurable as loadable modules.  There are already provisions to
> handle the automatic loading, and unloading of modules on a demand basis.

What about buffers allocated to a driver/module that is only used by a
process that has been sleeping for the last 3hrs?  What about page
tables for things that aren't running?  

Quote:> It's just not worth it.  The memory involved is too small, most of the
> kernel is too vital.

How does one find out how much space the kernel is consuming in code
and data?  (excluding buffers, of course.)

-wayne

--
Wayne Schlitt can not assert the truth of all statements in this
article and still be consistent.

1300 kB of unspappable kernel (code _and_ data)
8700 kB of swappable kernel (code _and_ data)

That is 87% swappable. Perhaps Linux is only 1/5 the size.
That would be 1740 kB swappable if the proportion is close.
(the NT system had very few processes, which means it did
not have the page tables and such that a busy Linux server
could swap)

--
--
Albert Cahalan <acahalan at cs.uml.edu> My address may be mangled to
avoid junk email. Please check it if you wish to respond to a news post.

On 21 Jun 1997 10:51:59 -0500,

--
____________________________________________________________________

                    Mark E. Levitt
    Department of Speech Communication, Syracuse University

         Home Page:  http://web.syr.edu/~melevitt

PGP fingerprint =  B8 A3 AA A6 0F 83 9A BE  F2 7A 19 F9 15 79 FE A4
Public key available from http://web.syr.edu/~melevitt/pgpkey.html
____________________________________________________________________

--
Torgeir Veimo, Vertech AS,