Re: [2.1.98] - It compiled and I ran...

Ian and Iris (
Mon, 27 Apr 1998 17:00:28 -0500

Point one: It stands to reason that there is some central memory
allocation routine which the entire kernel must use (like kmalloc,
maybe?) or else kmalloc would become confused about what memory is ok to
allocate. When a process is created, eg, you need space for the page
tables and such. Unless I misunderstand this worse than I think I do,
each and every time ANYTHING grabs memory, it must notify the kernel.
Further, when the memory is to be freed, the kernel must also be
notified. This means that the kernel must at least be able to come up
with a free block on demand, or know that none exist. Since there is a
central clearing house for memory use, then it also makes sense for that
to maintain a reverse reference. At 4k per page, 4-8 bytes saying what
the page belongs to and why add up to around 1/10 of a percent of system
memory if kept as a simple array. Faster and more efficient methods may
exist; this is left as an excercise. This must only be done for the size
of physical ram, not swap space. Also, this doesn't take much time.
Memory allocation is only a preparatory step. The system will spend far
more time USING the memory then allocating it.

Point two: If the kswapd expects to swap out a page, it must choose a
page which is swappable, and it must be able to determine what that page
is being used for so it can mark the page as being swapped out. This
means either there is SOME form of reverse mapping already, or else the
kswapd is doing forward lookups to find a page to swap, meaning it's
impossible to implement LRU swapping. LRU swapping is a
REAL GOOD THING(tm). LRU swapping is your friend. LRU swapping demands
that we kick pages based upon the age since last touched, which means
that we are given a page and must find which page table to update.

Point three: Defragmentation need not be done often, nor completely. My
(admittedly poor) understanding of the current kmalloc-scheme is that of
a buddy system. As kswapd knows which pages are candidates for swap,
and, one would hope, without "searching page tables", it is sufficent to
find some number of fragments (used blocks smaller than 64k with free
memory for a buddy) and pair them up.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to