# SOME DESCRIPTIVE TITLE # Copyright (C) YEAR The FreeBSD Project # This file is distributed under the same license as the FreeBSD Documentation package. # FIRST AUTHOR , YEAR. # #, fuzzy msgid "" msgstr "" "Project-Id-Version: FreeBSD Documentation VERSION\n" "POT-Creation-Date: 2025-05-01 19:56-0300\n" "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "Language: \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" #. type: YAML Front Matter: description #: documentation/content/en/books/arch-handbook/vm/_index.adoc:1 #, no-wrap msgid "Virtual Memory System in FreeBSD" msgstr "" #. type: YAML Front Matter: title #: documentation/content/en/books/arch-handbook/vm/_index.adoc:1 #, no-wrap msgid "Chapter 7. Virtual Memory System" msgstr "" #. type: Title = #: documentation/content/en/books/arch-handbook/vm/_index.adoc:14 #, no-wrap msgid "Virtual Memory System" msgstr "" #. type: Title == #: documentation/content/en/books/arch-handbook/vm/_index.adoc:52 #, no-wrap msgid "Management of Physical Memory `vm_page_t`" msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:55 msgid "" "Physical memory is managed on a page-by-page basis through the `vm_page_t` " "structure. Pages of physical memory are categorized through the placement of " "their respective `vm_page_t` structures on one of several paging queues." msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:57 msgid "" "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." msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:59 msgid "" "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." msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:61 msgid "" "Additionally, a page may be held with a reference count or locked with a " "busy count. The VM system also implements an \"ultimate locked\" state for a " "page using the PG_BUSY bit in the page's flags." msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:63 msgid "" "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." msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:65 msgid "" "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." msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:67 msgid "" "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 versus 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." msgstr "" #. type: Title == #: documentation/content/en/books/arch-handbook/vm/_index.adoc:69 #, no-wrap msgid "The Unified Buffer Cache `vm_object_t`" msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:72 msgid "" "FreeBSD implements the idea of a generic \"VM object\". VM objects can be " "associated with backing store of various typesunbacked, 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." msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:74 msgid "" "VM objects can be _shadowed_. 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." msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:76 msgid "" "It should be noted that a `vm_page_t` 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." msgstr "" #. type: Title == #: documentation/content/en/books/arch-handbook/vm/_index.adoc:78 #, no-wrap msgid "Filesystem I/O `struct buf`" msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:81 msgid "" "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." msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:83 msgid "" "The entities used to manage this are known as filesystem buffers, ``struct " "buf``'s, or ``bp``'s. When a filesystem needs to operate on a portion of a " "VM object, it typically maps part of the object into a struct buf and then " "maps the pages in the struct buf into KVM. In the same manner, disk I/O is " "typically issued by mapping portions of objects into buffer structures and " "then issuing the I/O on the buffer structures. The underlying vm_page_t's " "are typically busied for the duration of the I/O. Filesystem buffers also " "have their own notion of being busy, which is useful to filesystem driver " "code which would rather operate on filesystem buffers instead of hard VM " "pages." msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:85 msgid "" "FreeBSD reserves a limited amount of KVM to hold mappings from struct bufs, " "but it should be made clear that this KVM is used solely to hold mappings " "and does not limit the ability to cache data. Physical data caching is " "strictly a function of ``vm_page_t``'s, not filesystem buffers. However, " "since filesystem buffers are used to placehold I/O, they do inherently limit " "the amount of concurrent I/O possible. However, as there are usually a few " "thousand filesystem buffers available, this is not usually a problem." msgstr "" #. type: Title == #: documentation/content/en/books/arch-handbook/vm/_index.adoc:87 #, no-wrap msgid "Mapping Page Tables `vm_map_t, vm_entry_t`" msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:90 msgid "" "FreeBSD separates the physical page table topology from the VM system. All " "hard per-process page tables can be reconstructed on the fly and are usually " "considered throwaway. Special page tables such as those managing KVM are " "typically permanently preallocated. These page tables are not throwaway." msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:92 msgid "" "FreeBSD associates portions of vm_objects with address ranges in virtual " "memory through `vm_map_t` and `vm_entry_t` structures. Page tables are " "directly synthesized from the `vm_map_t`/`vm_entry_t`/ `vm_object_t` " "hierarchy. Recall that I mentioned that physical pages are only directly " "associated with a `vm_object`; that is not quite true. ``vm_page_t``'s are " "also linked into page tables that they are actively associated with. One " "`vm_page_t` can be linked into several _pmaps_, as page tables are called. " "However, the hierarchical association holds, so all references to the same " "page in the same object reference the same `vm_page_t` and thus give us " "buffer cache unification across the board." msgstr "" #. type: Title == #: documentation/content/en/books/arch-handbook/vm/_index.adoc:94 #, no-wrap msgid "KVM Memory Mapping" msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:97 msgid "" "FreeBSD uses KVM to hold various kernel structures. The single largest " "entity held in KVM is the filesystem buffer cache. That is, mappings " "relating to `struct buf` entities." msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:99 msgid "" "Unlike Linux, FreeBSD does _not_ map all of physical memory into KVM. This " "means that FreeBSD can handle memory configurations up to 4G on 32 bit " "platforms. In fact, if the mmu were capable of it, FreeBSD could " "theoretically handle memory configurations up to 8TB on a 32 bit platform. " "However, since most 32 bit platforms are only capable of mapping 4GB of ram, " "this is a moot point." msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:101 msgid "" "KVM is managed through several mechanisms. The main mechanism used to manage " "KVM is the _zone allocator_. The zone allocator takes a chunk of KVM and " "splits it up into constant-sized blocks of memory in order to allocate a " "specific type of structure. You can use `vmstat -m` to get an overview of " "current KVM utilization broken down by zone." msgstr "" #. type: Title == #: documentation/content/en/books/arch-handbook/vm/_index.adoc:103 #, no-wrap msgid "Tuning the FreeBSD VM System" msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:106 msgid "" "A concerted effort has been made to make the FreeBSD kernel dynamically tune " "itself. Typically you do not need to mess with anything beyond the " "`maxusers` and `NMBCLUSTERS` kernel config options. That is, kernel " "compilation options specified in (typically) [.filename]#/usr/src/sys/i386/" "conf/CONFIG_FILE#. A description of all available kernel configuration " "options can be found in [.filename]#/usr/src/sys/i386/conf/LINT#." msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:108 msgid "" "In a large system configuration you may wish to increase `maxusers`. Values " "typically range from 10 to 128. Note that raising `maxusers` too high can " "cause the system to overflow available KVM resulting in unpredictable " "operation. It is better to leave `maxusers` at some reasonable number and " "add other options, such as `NMBCLUSTERS`, to increase specific resources." msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:110 msgid "" "If your system is going to use the network heavily, you may want to increase " "`NMBCLUSTERS`. Typical values range from 1024 to 4096." msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:112 msgid "" "The `NBUF` parameter is also traditionally used to scale the system. This " "parameter determines the amount of KVA the system can use to map filesystem " "buffers for I/O. Note that this parameter has nothing whatsoever to do with " "the unified buffer cache! This parameter is dynamically tuned in 3.0-CURRENT " "and later kernels and should generally not be adjusted manually. We " "recommend that you _not_ try to specify an `NBUF` parameter. Let the system " "pick it. Too small a value can result in extremely inefficient filesystem " "operation while too large a value can starve the page queues by causing too " "many pages to become wired down." msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:114 msgid "" "By default, FreeBSD kernels are not optimized. You can set debugging and " "optimization flags with the `makeoptions` directive in the kernel " "configuration. Note that you should not use `-g` unless you can accommodate " "the large (typically 7 MB+) kernels that result." msgstr "" #. type: delimited block . 4 #: documentation/content/en/books/arch-handbook/vm/_index.adoc:119 #, no-wrap msgid "" "makeoptions DEBUG=\"-g\"\n" "makeoptions COPTFLAGS=\"-O -pipe\"\n" msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:122 msgid "" "Sysctl provides a way to tune kernel parameters at run-time. You typically " "do not need to mess with any of the sysctl variables, especially the VM " "related ones." msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:124 msgid "" "Run time VM and system tuning is relatively straightforward. First, use Soft " "Updates on your UFS/FFS filesystems whenever possible. [.filename]#/usr/src/" "sys/ufs/ffs/README.softupdates# contains instructions (and restrictions) on " "how to configure it." msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:126 msgid "" "Second, configure sufficient swap. You should have a swap partition " "configured on each physical disk, up to four, even on your \"work\" disks. " "You should have at least 2x the swap space as you have main memory, and " "possibly even more if you do not have a lot of memory. You should also size " "your swap partition based on the maximum memory configuration you ever " "intend to put on the machine so you do not have to repartition your disks " "later on. If you want to be able to accommodate a crash dump, your first " "swap partition must be at least as large as main memory and [.filename]#/var/" "crash# must have sufficient free space to hold the dump." msgstr "" #. type: Plain text #: documentation/content/en/books/arch-handbook/vm/_index.adoc:127 msgid "" "NFS-based swap is perfectly acceptable on 4.X or later systems, but you must " "be aware that the NFS server will take the brunt of the paging load." msgstr ""