cvs commit: de-docproj/books/arch-handbook/vm chapter.sgml

From: Johann Kois <jkois(at)doc.bsdgroup.de>
Date: Sat, 7 Feb 2009 11:12:15 GMT

jkois 2009-02-07 11:12:15 UTC

FreeBSD German Documentation Repository

Modified files:
    books/arch-handbook/vm chapter.sgml
  Log:
  Übersetzung des VM-Kapitels - Initiale Version, noch nicht bereit für MFde.

  Was fehlt noch:
  - gegenlesen
  - Deutsche Rechtschreibung
  - Markup (das Dokument entspricht nicht den Vorgaben des FDP
  - - </para>-Tags nie in einer eigenen Zeile.
  - - Vorgabe für maximale Zeilenlänge nicht erfüllt.

  Revision Changes Path
  1.2 +226 -221 de-docproj/books/arch-handbook/vm/chapter.sgml

  Index: chapter.sgml
  ===================================================================
  RCS file: /home/cvs/de-docproj/books/arch-handbook/vm/chapter.sgml,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -I$FreeBSDde.*$ -r1.1 -r1.2
  --- chapter.sgml 25 Aug 2007 04:28:40 -0000 1.1
  +++ chapter.sgml 7 Feb 2009 11:12:15 -0000 1.2
  @@ -19,256 +19,261 @@
       
     </chapterinfo>

  - <title>Virtual Memory System</title>
  + <title>Virtuelles Speichersystem</title>

       <sect1 id="vm-physmem">
  - <title>Management of physical
  - memory—<literal>vm_page_t</literal></title>
  + <title>Verwaltung des physischen Speichers—<literal>vm_page_t</literal></title>

  - <indexterm><primary>virtual memory</primary></indexterm>
  - <indexterm><primary>physical memory</primary></indexterm>
  - <indexterm><primary><literal>vm_page_t</literal> structure</primary></indexterm>
  - <para>Physical memory is managed on a page-by-page basis through the
  - <literal>vm_page_t</literal> structure. Pages of physical memory are
  - categorized through the placement of their respective
  - <literal>vm_page_t</literal> structures on one of several paging
  - queues.</para>
  -
  - <para>A page can be in a wired, active, inactive, cache, or free state.
  - Except for the wired state, the page is typically placed in a doubly
  - link list queue representing the state that it is in. Wired pages
  - are not placed on any queue.</para>
  -
  - <para>FreeBSD implements a more involved paging queue for cached and
  - free pages in order to implement page coloring. Each of these states
  - involves multiple queues arranged according to the size of the
  - processor's L1 and L2 caches. When a new page needs to be allocated,
  - FreeBSD attempts to obtain one that is reasonably well aligned from
  - the point of view of the L1 and L2 caches relative to the VM object
  - the page is being allocated for.</para>
  -
  - <para>Additionally, a page may be held with a reference count or locked
  - with a busy count. The VM system also implements an <quote>ultimate
  - locked</quote> state for a page using the PG_BUSY bit in the page's
  - flags.</para>
  -
  - <para>In general terms, each of the paging queues operates in a LRU
  - fashion. A page is typically placed in a wired or active state
  - initially. When wired, the page is usually associated with a page
  - table somewhere. The VM system ages the page by scanning pages in a
  - more active paging queue (LRU) in order to move them to a less-active
  - paging queue. Pages that get moved into the cache are still
  - associated with a VM object but are candidates for immediate reuse.
  - Pages in the free queue are truly free. FreeBSD attempts to minimize
  - the number of pages in the free queue, but a certain minimum number of
  - truly free pages must be maintained in order to accommodate page
  - allocation at interrupt time.</para>
  -
  - <para>If a process attempts to access a page that does not exist in its
  - page table but does exist in one of the paging queues (such as the
  - inactive or cache queues), a relatively inexpensive page reactivation
  - fault occurs which causes the page to be reactivated. If the page
  - does not exist in system memory at all, the process must block while
  - the page is brought in from disk.</para>
  -
  - <indexterm><primary>paging queues</primary></indexterm>
  -
  - <para>FreeBSD dynamically tunes its paging queues and attempts to
  - maintain reasonable ratios of pages in the various queues as well as
  - attempts to maintain a reasonable breakdown of clean vs. dirty pages.
  - The amount of rebalancing that occurs depends on the system's memory
  - load. This rebalancing is implemented by the pageout daemon and
  - involves laundering dirty pages (syncing them with their backing
  - store), noticing when pages are activity referenced (resetting their
  - position in the LRU queues or moving them between queues), migrating
  - pages between queues when the queues are out of balance, and so forth.
  - FreeBSD's VM system is willing to take a reasonable number of
  - reactivation page faults to determine how active or how idle a page
  - actually is. This leads to better decisions being made as to when to
  - launder or swap-out a page.</para>
  + <indexterm><primary>Virtueller Speicher</primary></indexterm>
  + <indexterm><primary>Physischer Speicher</primary></indexterm>
  + <indexterm><primary><literal>vm_page_t</literal>—Struktur</primary></indexterm>
  + <para>Der physische Speicher wird seitenweise durch die
  + <literal>vm_page_t</literal>—Struktur verwaltet.
  + Die physischen Speicherseiten unterscheiden sich durch die Anordnung der zugehörigen
  + <literal>vm_page_t</literal>—Struckturen in einer der Warteschlangen für
  + Speicherseiten.</para>
  +
  + <para>Eine Speicherseite kann in verdrahtetem, aktiven, inaktiven, zwischengespeicherten (cached) oder
  + freiem Zustand sein. Wenn nicht verdrahtet, befindet sich eine Speicherseite in einer
  + ihren Zustand repräsentierenden, doppelt verlinkten Warteschlange. Verdrahtete Speicherseiten
  + befinden sich nicht in einer Warteschlange.</para>
  +
  + <para>FreeBSD implementiert eine kombinierte Warteschlange für zwischengespeicherte und freie
  + Seiten, um
  + Seiteneinfärben zu implementieren. Jeder der Zustände benutzt mehrere Warteschlangen,
  + arrangiert entsprechend der Größe der L1- und L2-Caches des Prozessors.
  + Wenn eine neue Seite angelegt werden muss, versucht FreeBSD eine Warteschlange
  + auszuwählen, die bezüglich L1- und L2-Cache, verglichen mit dem VM-Objekt, für das
  + die Speicherseite angelegt wird, wohlproportioniert erscheint.</para>
  +
  + <para>Zusätzlich kann eine Seite mit einem Referenzzähler versehen oder aber mit einem
  + Belegtzähler gesperrt werden. Das VM-System implementiert auch einen <quote>ultimate
  + locked</quote>—Zustand für eine Speicherseite, dessen PG_BUSY-Bit in der Seitenmaske
  + gesetzt ist.</para>
  +
  + <para>Im allgemeinen arbeitet jede der Warteschlangen im LRU-Modus (last recently used - zuletzt benutzt).
  + Gewöhnlich befindet sich eine Speicherseite anfangs in verdrahtetem oder aktiven Zustand.
  + Wenn sie verdrahtet ist, ist sie normalerweise mit einer Speichertabelle verbunden.
  + Das VM-System läßt eine Seite dadurch altern, daß es eine aktivere Warteschlange (LRU)
  + durchsucht und sie in eine weniger aktive Warteschlange einreiht. Speicherseiten im Zwischenspeicher sind noch mit
  + einem VM-Objekt verbunden, sind aber Kandidaten für eine sofortige Wiederverwendung. Speicherseiten
  + in der freien Warteschlange sind wirklich frei. FreeBSD versucht, die Anzahl der Speicherseiten in der
  + freien Warteschlange zu minimieren. Ein gewisses Minimum an freien Speicherseiten ist aber notwendig, um
  + Speicherseitenanlegung im Interruptzustand zu ermöglichen.</para>
  +
  + <para>Wenn ein Prozeß versucht auf eine Seite zuzugreifen, die nicht in seiner Speichertabelle,
  + aber in einer der Warteschlangen (z.B. eine mit inaktiven oder zwischengespeicherten Seiten) zu
  + finden ist, wird ein relativ unaufwendiger Speicherseitenfehler zur Reaktivierung audsgelößt.
  + Ist die Seite allerdings nicht im Systemspeicher, ist der Prozeß blockiert, bis die Seite von
  + der Festplatte geholt wurde.</para>
  +
  + <indexterm><primary>Warteschlangen für Speicherseiten</primary></indexterm>
  +
  + <para>FreeBSD versucht dynamisch, eine gute Balance zwischen Seiten in den verschiedenen
  + Warteschlangen als auch zwischen "sauberen" und "schmutzigen" Seiten herzustellen. Der dazu
  + betriebene Aufwand hängt von der Last für den Systemspeicher ab. Es ist implementiert
  + durch einen Systemprozeß zur Speicherauslagerung (pageout daemon). Er hat Aufgaben wie das
  + "Waschen schmutziger Seiten" (Abgleichen mit dem permanenten Speicher), Benachrichtigen, wenn Seiten
  + benutzt werden (Zurücksetzen in den LRU-Warteschlangen, Verschieben zwischen den
  + Warteschlangen), Verschieben zwischen den Warteschlangen, wenn sie nicht mehr balanciert sind usw.
  + FreeBSDs virtuelles Speichersystem nimmt eine gewisse Zahl von Speicherfehlern zur Reaktivierung in
  + Kauf, um festzustellen, wie aktiv oder unbenutzt eine Seite wirklich ist. So kann besser entschieden
  + werden, wann eine Seite "gewaschen" oder ausgelagert wird.</para>
       </sect1>

       <sect1 id="vm-cache">
  - <title>The unified buffer
  - cache—<literal>vm_object_t</literal></title>
  + <title>Das einheitliche Zwischenspeicher—<literal>vm_object_t</literal></title>

  - <indexterm><primary>unified buffer cache</primary></indexterm>
  - <indexterm><primary><literal>vm_object_t</literal> structure</primary></indexterm>
  + <indexterm><primary>Die einheitliche Zwischenspeicher</primary></indexterm>
  + <indexterm><primary><literal>vm_object_t</literal>—Struktur</primary></indexterm>

  - <para>FreeBSD implements the idea of a generic <quote>VM object</quote>.
  - VM objects can be associated with backing store of various
  - types—unbacked, swap-backed, physical device-backed, or
  - file-backed storage. Since the filesystem uses the same VM objects to
  - manage in-core data relating to files, the result is a unified buffer
  - cache.</para>
  -
  - <para>VM objects can be <emphasis>shadowed</emphasis>. That is, they
  - can be stacked on top of each other. For example, you might have a
  - swap-backed VM object stacked on top of a file-backed VM object in
  - order to implement a MAP_PRIVATE mmap()ing. This stacking is also
  - used to implement various sharing properties, including
  - copy-on-write, for forked address spaces.</para>
  -
  - <para>It should be noted that a <literal>vm_page_t</literal> can only be
  - associated with one VM object at a time. The VM object shadowing
  - implements the perceived sharing of the same page across multiple
  - instances.</para>
  + <para>FreeBSD implementiert die Idee eines generischen <quote>VM-Objekts</quote>. VM-Objekte können
  + mit verschiedenen Arten von Hintergrundspeicher asoziiert werden, mit Swabspeicher, einem physischen
  + Gerät oder aber einer datei. Da das Dateisystem die gleichen VM-Objekte benutzt, um
  + Kernel-Data, die zu Dateien gehören, zu verwakten, entsteht ein einheitlicher Zwischenspeicher.
  + </para>
  +
  + <para>VM-Objekte können sich <emphasis>überschatten</emphasis>. Das heißt, sie
  + können übereinandergelegt werden. Z.B. kann ein swap-assoziertes über ein
  + dateiassoziertes gelegt werden, um MAP_PRIVATE mmap()ing zu implementieren. Das
  + Übereinanderlegen wird benutzt, um verschiedene Mechanismen zum Teilen zu implementieren,
  + eingeschlossen coy-on-write (Kopieren, wenn geschrieben wird) für
  + forked address spaces.</para>
  +
  + <para>Eine<literal>vm_page_t</literal>—Struktur kann nur mit einem VM-Objekt assoziert werden.
  + Das VM-Objekt-Überschatten implementiert das perceived sharing einer Seite zwischen mehreren
  + Instanzen.</para>
       </sect1>

       <sect1 id="vm-fileio">
  - <title>Filesystem I/O—<literal>struct buf</literal></title>
  + <title>Dateisystem-Ein—/Ausgabe—<literal>struct buf</literal></title>

         <indexterm><primary>vnode</primary></indexterm>
  - <para>vnode-backed VM objects, such as file-backed objects, generally
  - need to maintain their own clean/dirty info independent from the VM
  - system's idea of clean/dirty. For example, when the VM system decides
  - to synchronize a physical page to its backing store, the VM system
  - needs to mark the page clean before the page is actually written to
  - its backing store. Additionally, filesystems need to be able to map
  - portions of a file or file metadata into KVM in order to operate on
  - it.</para>
  -
  - <para>The entities used to manage this are known as filesystem buffers,
  - <literal>struct buf</literal>'s, or

----------------------------------------------
Diff block truncated. (Max lines = 200)
----------------------------------------------

To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-cvs-doc" in the body of the message
Received on Sat 07 Feb 2009 - 12:12:31 CET