The Linux memory manager implements demand paging with a copy-on-write
strategy relying on the 386's paging support. A process acquires its
page tables from its parent (during a <#1857#> fork()<#1857#>) with the entries
marked as read-only or swapped. Then, if the process tries to write
to that memory space, and the page is a copy-on-write page, it is
copied, and the page is marked read-write. An <#1858#> exec()<#1858#> results in
the reading in of a page or so from the executable. The process then
faults in any other pages it needs.
Each process has a page directory which means it can access 1 KB of
page tables pointing to 1 MB of 4 KB pages which is 4 GB of memory. A
process' page directory is initialized during a fork by <#1859#>
copy_page_tables()<#1859#>. The idle process has its page directory
initialized during the initialization sequence.
Each user process has a local descriptor table that contains a code
segment and data-stack segment. These user segments extend from 0 to
3~GB~(0xc0000000). In user space linear addresses and logical
addresses are identical.
The kernel code and data segments are privileged segments defined in the
global descriptor table and extend from 3~GB to 4~GB. The swapper page
directory (<#1862#> swapper_page_dir<#1862#> is set up so that logical addresses
and physical addresses are identical in kernel space.
The space above 3~GB appears in a process' page directory as pointers
to kernel page tables. This space is invisible to the process in user
mode but the mapping becomes relevant when privileged mode is entered,
for example, to handle a system call.
Supervisor mode is entered within the context of the current process
so address translation occurs with respect to the process' page
directory but using kernel segments. This is identically the mapping
produced by using the <#1863#> swapper_pg_dir<#1863#> and kernel segments as
both page directories use the same page tables in this space. Only
<#1864#> task[0]<#1864#> (the idle task <#1866#> [This should be
documented earlier in this guide...]<#1866#>) uses the <#1867#>
swapper_pg_dir<#1867#> directly.
- The user process' <#1869#> segment_base<#1869#> = 0x00, <#1870#> page_dir<#1870#>
private to the process.
- user process makes a system call: <#1871#> segment_base<#1871#>=0xc0000000
<#1872#> page_dir<#1872#> = same user <#1873#> page_dir<#1873#>.
- <#1874#> swapper_pg_dir<#1874#> contains a mapping for all physical pages
from 0xc0000000 to 0xc0000000 + <#1875#> end_mem<#1875#>,
so the first 768 entries in <#1876#> swapper_pg_dir<#1876#> are 0's, and
then there are 4 or more that point to kernel page tables.
- The user page directories have the same entries as <#1877#>tt swapper_pg_dir<#1877#>
above 768. The first 768 entries map the user space.
The upshot is that whenever the linear address is above 0xc0000000
everything uses the same kernel page tables.
The user stack sits at the top of the user data segment and grows down.
The kernel stack is not a pretty data structure or segment that I can
point to with a ``yon lies the kernel stack.'' A <#1879#> kernel_stack_frame<#1879#>
(a page) is associated with each newly created process and is used
whenever the kernel operates within the context of that process. Bad
things would happen if the kernel stack were to grow below its current
stack frame. <#1880#> [Where is the kernel stack put? I know that there
is one for every process, but where is it stored when it's not being used?]<#1880#>
User pages can be stolen or swapped. A user page is one that is mapped
below 3~GB in a user page table. This region does not contain page
directories or page tables. Only dirty pages are swapped.
Minor alterations are needed in some places (tests for process memory
limits comes to mind) to provide support for programmer defined segments.