Only those parts of the program and data that are
currently in active use need to be held in physical RAM. Other parts are
then held in a swap file (as it’s called in Windows 95/98/ME:
Win386.swp) or page file (in Windows NT versions including Windows
2000 and XP: pagefile.sys). When a program tries to access some address that
is not currently in physical RAM, it generates an interrupt, called a Page Fault. This asks the system to retrieve the 4 KB page containing
the address from the page file (or in the case of code possibly from the
original program file). This — a valid page fault — normally happens quite
invisibly. Sometimes, through program or hardware error, the page is not
there either. The system then has an ‘Invalid Page Fault’ error.
If there is pressure on space in RAM, then
parts of code and data that are not currently needed can be ‘paged out’ in
order to make room — the page file can thus be seen as an overflow area to
make the RAM behave as if it were larger than it is.
|
PAGE FAULTS |
Once an executable image has been memory mapped
into a process' virtual memory it can start to execute. As only the very
start of the image is physically pulled into memory it will soon access an
area of virtual memory that is not yet in physical memory. When a process
accesses a virtual address that does not have a valid page table entry, the
processor will report a page fault to Linux.
The page fault describes the virtual address where the page fault
occurred and the type of memory access that caused the fault. Linux must
find the area of memory in which the page fault occurred in. This is done
through the vm_area_struct kernel data structure. As searching
through the vm_area_struct data structures is critical to the
efficient handling of page faults, these are linked together in an AVL (Adelson-Velskii
and Landis) tree structure. (An AVL tree structure is a balanced binary
search tree where the height of the two subtrees (children) of a node
differs by at most one, thus optimizing searches.) If there is no
vm_area_struct data structure for this faulting virtual address, this
process has accessed an illegal virtual address. Linux will signal the
process, sending a SIGSEGV signal and if the process does not have
a handler for that signal it will be terminated.
Linux next checks the type of page fault that occurred against the types
of accesses allowed for this area of virtual memory. If the process is
accessing the memory in an illegal way, say writing to an area that it is
only allowed to read from, it is also signalled with a memory error.
Now that Linux has determined that the page fault is legal, it must deal
with it.
Linux must differentiate between pages that are in the swap file and
those that are part of an executable image on a disk somewhere. It does this
by using the page table entry for this faulting virtual address.
If the page's page table entry is invalid but not empty, the page fault
is for a page currently being held in the swap file. For Alpha AXP page
table entries, these are entries which do not have their valid bit set but
which have a non-zero value in their PFN field. In this case the PFN field
holds information about where in the swap (and which swap file) the page is
being held. How pages in the swap file are handled is described later in
this chapter.
Not all
vm_area_struct data structures have a set of virtual
memory operations and even those that do may not have a nopage
operation. This is because by default Linux will fix up the access by
allocating a new physical page and creating a valid page table entry for it.
If there is a nopage operation for this area of virtual memory,
Linux will use it.
The generic Linux nopage operation is used for memory mapped
executable images and it uses the page cache to bring the required image
page into physical memory.
However the required page is brought into physical memory, the process'
page tables are updated. It may be necessary for hardware specific actions
to update those entries, particularly if the processor uses translation look
aside buffers. Now that the page fault has been handled it can be dismissed
and the process is restarted at the instruction that made the faulting
virtual memory access.
|
There is a great deal of myth surrounding this
question. Two big fallacies are:
- The file should be a fixed size so that it does not get fragmented,
with minimum and maximum set the same
- The file should be 2.5 times the size of RAM (or some other multiple)
Both are wrong in a modern, single-user system. A machine using Fast User
switching is a special case, discussed.
Windows will expand a file that starts out too small and may shrink it
again if it is larger than necessary, so it pays to set the initial size as
large enough to handle the normal needs of your system to avoid
constant changes of size. This will give all the benefits claimed for a
‘fixed’ page file. But no restriction should be placed on its further
growth. As well as providing for contingencies, like unexpectedly opening a
very large file, in XP this potential file space can be used as a
place to assign those virtual memory pages that programs have asked for, but
never brought into use. Until they get used — probably never — the file need
not come into being. There is no downside in having potential space
available.
For any given workload, the total need for virtual addresses will not
depend on the size of RAM alone. It will be met by the sum of RAM and
the page file. Therefore in a machine with small RAM, the extra amount
represented by page file will need to be larger — not smaller — than that
needed in a machine with big RAM. Unfortunately the default settings for
system management of the file have not caught up with this: it will assign
an initial amount that may be quite excessive for a large machine, while at
the same leaving too little for contingencies on a small one.
How big a file will turn out to be needed depends very much on your
work-load. Simple word processing and e-mail may need very little — large
graphics and movie making may need a great deal. For a general workload,
with only small dumps provided for , it is suggested that a sensible
start point for the initial size would be the greater of (a)
100 MB or (b) enough to bring RAM plus file to about 500 MB. EXAMPLE: Set the Initial page file size to 400 MB on a
computer with 128 MB RAM; 250 on a 256 MB computer; or 100 MB for larger
sizes.
But have a high Maximum size — 700 or 800 MB or even more if there is
plenty of disk space. Having this high will do no harm. Then if you find the
actual pagefile.sys gets larger (as seen in Explorer), adjust the initial
size up accordingly. Such a need for more than a minimal initial page file
is the best indicator of benefit from adding RAM: if an initial size set,
for a trial, at 50MB never grows, then more RAM will do nothing for the
machine's performance.
Bill James MS MVP has a convenient tool, ‘WinXP-2K_Pagefile’, for
monitoring the actual usage of the Page file, which can be downloaded . The value
seen for ‘Peak Usage’ over several days makes a good guide for setting the
Initial size economically.
Note that these aspects of Windows XP have changed significantly from
earlier Windows NT versions, and practices that have been common there may
no longer be appropriate. Also, the ‘PF Usage’ (Page File in Use)
measurement in Task Manager | Performance for ‘Page File
in Use’ include those potential uses by pages that have not been
taken up. It makes a good indicator of the adequacy of the ‘Maximum’ size
setting, but not for the ‘Initial’ one, let alone for any need for more RAM. |
PAGE SIZE |
Most modern operating systems have their main
memory divided into pages. It allows better utilization of memory. A page is
a fixed length block of main memory, that is contiguous in both physical
memory addressing and virtual memory addressing. Kernel swap and allocates
memory using pagesWhether getpagesize() is present as a
Linux system call depends on the
architecture. If it is, it returns the kernel symbol PAGE_SIZE, which is
architecture and machine model dependent. Generally, one uses binaries that
are architecture but not machine model dependent, in order to have a single
binary distribution per architecture. This means that a user program should
not find PAGE_SIZE at compile time from a header file, but use an actual
system call, at least for those architectures (like sun4) where this
dependency exists. Here libc4, libc5, glibc 2.0 fail because their
getpagesize() returns a statically derived value, and does not use a
system call. Things are OK in glibc 2.1.
|
To maintain peak performance, Windows XP is much like its
predecessors in that it pays to slam in the RAM. Indeed, running low on
physical RAM is one of the most common reasons why Windows computers crawl
rather than operate to their full potential.
When a Windows XP computer runs low on RAM, it begins a
process called paging - or memory swapping if you’re used to using a Windows
9*/Me based operating system. The paging process involves moving blocks (or
pages) of data out of physical memory and onto disk.
A small amount of paging is perfectly normal on most
computers, but unnecessary paging should be avoided at all cost. Excessive
paging, sometimes called thrashing, becomes a problem when the hard disk
goes into overdrive as it tries to shuffle data to and from RAM.
Hence, the best way to avoid thrashing of the disk is to
install plenty of RAM. Fine-tuning your virtual memory settings is also a
good way to boost system performance and we’ll show you how to do just that
in a moment. First, though, let’s cover the basics in a little more detail.
There are only a few ways to deal with
thrashing when it occurs:
-
Increase the
amount of RAM in the system to eliminate the cause of thrashing
-
Reduce the amount
of RAM needed by reconfiguring the applications, removing unneeded system
services (like network protocols that aren't being used), or running fewer
applications at a time
-
Try to optimize
the paging file's activity
|
THRASHING |
"In a
multiprogramming environment, allocated memory pages of a program will
become replacement candidates if they have not been accessed for a certain
period of time under two conditions: (1) the program does not need to access
these pages; and (2) the program is conducting page faults (as a sleeping
process) so that it is not able to access the pages although it might have
done so without the page faults. We call the LRU pages generated by
condition (1) true LRU pages, and those by condition (2) false LRU pages.
These false LRU pages are produced by the time delay of page faults, not by
the access delay of the program. Thus, the LRU principle is not held in this
case.
Whenever page faults
occur due to memory shortage in a multiprogramming environment, false LRU
pages of a program can be generated, which will weaken the ability of the
program to achieve its working set. For example, if a program does not
access the already obtained memory pages on the false LRU condition, these
pages may become replacement candidates (LRUpages) when the memory space is
being demanded by other interacting programs. When the program is ready to
use these pages in its execution turn, these LRU pages may have been
replaced to satisfy requested allocations of other programs. The program
then has to ask the virtual memory system to retrieve these pages by
replacing LRU pages of others, possibly generating false LRU pages for other
programs. The false LRU pages may be cascaded among the interacting
programs, eventually causing system thrashing."
The factor related to thrashing :-
- the
size of memory system
- the number of processes
- the dynamic memory demands
- the page replacement scheme
|
A program instruction on an Intel 386 or later
CPU can address up to 4GB of memory, using its full 32 bits. This is
normally far more than the RAM of the machine. (The 32nd exponent of 2 is
exactly 4,294,967,296, or 4 GB. 32 binary digits allow the representation of
4,294,967,296 numbers — counting 0.) So the hardware provides for
programs to operate in terms of as much as they wish of this full 4GB space
as Virtual Memory, those parts of the program and data which are
currently active being loaded into Physical Random Access Memory
(RAM). The processor itself then translates (‘maps’) the virtual addresses
from an instruction into the correct physical equivalents, doing this on the
fly as the instruction is executed. The processor manages the mapping in
terms of pages of 4 Kilobytes each - a size that has implications for
managing virtual memory by the system. |
DEFINITION |
The term "Virtual Memory" is used to describe a method by
which the physical RAM of a computer is not directly addressed, but is
instead accessed via an indirect "lookup". On the Intel platform, paging is
used to accomplish this task.
Paging, in CPU specific terms, should not be confused
with swap. These terms are related, but paging is used to refer to virtual
to physical address translation. The author encourages readers to find the
Intel Manuals online or order them in print for a deeper understanding of
the Intel paging system. (Note - In Intel documents, the term virtual
address, as used in the kernel code, is replaced with linear address).
To accomplish address translation (paging) the CPU needs
to be told:
a) where to find the address translation information.
This is accomplished by pointing the CPU to a lookup table called a 'page
table'. b) to activate paging mode. This is accomplished by setting a
specific flag in a control register.
Kernel use of virtual memory begins very early on in the
boot process. head.S contains code to create provisional page tables and get
the kernel up and running, however that is beyond this overview.
Every physical page of memory up to 896MB is mapped
directly into the kernel space. Memory greater than 896MB (High Mem) is not
permanently mapped, but is instead temporarily mapped using kmap and
kmap_atomic.
The descriptions of virtual memory will be broken into
two distinct sections; kernel paging and user process paging.
|
0 comments:
Post a Comment