Project locked to follow the migration to Hugo/AsciiDoctor, sorry for the inconvenience and please wait a few days to continue with the translations.

The translation is temporarily closed for contributions due to maintenance, please come back later.
Language Translated Untranslated Untranslated words Checks Suggestions Comments
English This translation is used for source strings. This component is linked to the FreeBSD Doc (Archived)/articles_bsdl-gpl repository. This translation is locked. BSD-2-Clause-FreeBSD 6
Portuguese (Brazil) This component is linked to the FreeBSD Doc (Archived)/articles_bsdl-gpl repository. This translation is locked. BSD-2-Clause-FreeBSD 98% 2 55 12
Spanish This component is linked to the FreeBSD Doc (Archived)/articles_bsdl-gpl repository. This translation is locked. BSD-2-Clause-FreeBSD 7 2 4
Start new translation
Please sign in to see the alerts.
Project website wiki.freebsd.org/DocTranslationOnWeblate
Instructions for translators

https://wiki.freebsd.org/DocTranslationOnWeblate Mailing list for translators: <<freebsd-translators@freebsd.org>

Translation process
  • Translations can be made directly.
  • Translation suggestions can be made.
  • Only chosen users can contribute.
  • The translation uses bilingual files.
Translation license BSD-2-Clause-FreeBSD
Filemask articles/*/vm-design.po
Languages 3
Source strings 108
Source words 6,681
Source characters 40,633
Hosted strings 324
Hosted words 20,043
Hosted characters 121,899
Component locked a month ago
FreeBSD manages all of this with a layered VM Object model. The original binary program file winds up being the lowest VM Object layer. A copy-on-write layer is pushed on top of that to hold those pages which had to be copied from the original file. If the program modifies a data page belonging to the original file the VM system takes a fault and makes a copy of the page in the higher layer. When a process forks, additional VM Object layers are pushed on. This might make a little more sense with a fairly basic example. A <function>fork()</function> is a common operation for any *BSD system, so this example will consider a program that starts up, and forks. When the process starts, the VM system creates an object layer, let's call this A:
FreeBSD gestinoa todo esto con un modelo de Objetos de Memoria Virtual en capas. El fichero del programa binario original termina siendo la capa de Objetos de Memoria Virtual más baja. Una capa copy-on-write se sitúa encima de ella para mantener aquellas páginas que han sido copiadas del fichero original. Si el programa modifica una página de datos que pertenece al fichero original el sistema de Memoria Virtual generarecibe un fallo de página y hace una copia de la página en la capa superior. Cuando un proceso bifurca, se empujan nuevas capas de Objetos de Memoria Virtual. Esto puede cobrar más sentido con un ejemplo bastante básico. Un <function>fork()</function> es una operación común para cualquier sistema *BSD, así que este ejemplo considerará un programa que arranca, y bifurca. Cuando el proceso arranca, el sistema de Memoria Virtual crea una capa de objetos, llamémosla A:
a month ago
Note that I say <quote>reasonably</quote> contiguous rather than simply <quote>contiguous</quote>. From the point of view of a 128K direct mapped cache, the physical address 0 is the same as the physical address 128K. So two side-by-side pages in your virtual address space may wind up being offset 128K and offset 132K in physical memory, but could also easily be offset 128K and offset 4K in physical memory and still retain the same cache performance characteristics. So page-coloring does <emphasis>not</emphasis> have to assign truly contiguous pages of physical memory to contiguous pages of virtual memory, it just needs to make sure it assigns contiguous pages from the point of view of cache performance and operation.
Nótese que digo <quote>razonablemente</quote> contiguas en lugar de simplemente <quote>contiguas</quote>. Desde el punto de vista de una caché de mapeo directo de 128K, la dirección física 0 es la misma que la dirección física 128K. De modo que dos páginas una al lado de la otra en tu espacio de memoria virtual podrían terminar siendo el desplazamiento 128K y 132K en memoria física, pero podría fácilmente ser también el desplazamiento 128K y 4K en memoria física y mantener todavía las mismas características de rendimiento de la caché. Así que el coloreado de páginas <emphasis>no</emphasis> tiene que asignar páginas de memoria física realmente contiguas a páginas de memoria virtual que sí lo son, sólo necesita asegurarse de que asigna páginas contiguas desde el punto de vista del rendimiento y la operativa de la caché.
a month ago
This is what Page coloring does. Instead of assigning <emphasis>random</emphasis> physical pages to virtual addresses, which may result in non-optimal cache performance, Page coloring assigns <emphasis>reasonably-contiguous</emphasis> physical pages to virtual addresses. Thus programs can be written under the assumption that the characteristics of the underlying hardware cache are the same for their virtual address space as they would be if the program had been run directly in a physical address space.
Esto es lo que hace el coloreado de páginas. En lugar de asignar páginas físicas de forma <emphasis>aleatoria</emphasis>, lo que podría resultar en un rendimiento de caché no óptimo, el coloreado de Páginas asigna páginas físicas <emphasis>razonablemente contiguas</emphasis> a direcciones virtuales. Por lo tanto los programas se pueden escribir asumiendo que las características de la caché hardware subyacente son las mismas para el espacio de direcciones virtuales a como serían si el programa estuviera ejecutándose directamente en un espacio de direcciones físicas.
a month ago
A program normally assumes that two side-by-side pages will be optimally cached. That is, that you can access data objects in both pages without having them blow away each other's cache entry. But this is only true if the physical pages underlying the virtual address space are contiguous (insofar as the cache is concerned).
Un programa normalmente asume que dos páginas que están una al lado de la otra serán cacheadas de forma óptima. Es decir, que puedes acceder a objetos de datos en ambas páginas sin tener que destrozar las entradas de caché de la otra página. Pero esto sólo es cierto si las páginas físicas bajo el espacio de memoria virtual son contiguas (en lo que a la caché se refiere).
a month ago
But in the <trademark class="registered">UNIX</trademark> world you are dealing with virtual address spaces, not physical address spaces. Any program you write will see the virtual address space given to it. The actual <emphasis>physical</emphasis> pages underlying that virtual address space are not necessarily physically contiguous! In fact, you might have two pages that are side by side in a processes address space which wind up being at offset 0 and offset 128K in <emphasis>physical</emphasis> memory.
Pero en el mundo <trademark class="registered">UNIX</trademark> tú tratas con espacios de direcciones virtuales, no espacios de direcciones físicas. Cualquier programa que escribas verá un espacio de direcciones virtuales que se le ha proporcionado. Las páginas virtuales<emphasis>reales</emphasis> que están por debajo del espacio de direcciones virtuales ¡no están necesariamente contiguas físicamente! De hecho, podrías tener dos páginas que están pegadas una a la otra en el espacio de direcciones del proceso y que terminan estando en el desplazamiento 0 y el desplazamiento 128K en memoria<emphasis>física</emphasis>.
a month ago
Ok, so now onto page coloring: All modern memory caches are what are known as <emphasis>physical</emphasis> caches. They cache physical memory addresses, not virtual memory addresses. This allows the cache to be left alone across a process context switch, which is very important.
Ok, ahora vamos con el coloreado de páginas: Todas las memorias caché modernas con lo que que se conoce como cachés <emphasis>físicas</emphasis>. Cachean direcciones de memoria física, no direcciones de memoria virtual. Esto permite no molestar a la caché durante un cambio de contexto de procesos, lo que es muy importante.
a month ago
Ok, so now onto page coloring: All modern memory caches are what are known as <emphasis>physical</emphasis> caches. They cache physical memory addresses, not virtual memory addresses. This allows the cache to be left alone across a process context switch, which is very important.
Ok, ahora vamos con el coloreado de páginas: Todas las memorias caché modernas con lo que que se conoce como cachés <emphasis>físicas</emphasis>. Cachean direcciones de memoria física, no direcciones de memoria virtual. Esto permite no molestar a la caché durante un cambio de contexto de procesos, lo que es muy importante.
a month ago
It is extremely important… <emphasis>extremely</emphasis> important for most of a processor's memory accesses to be able to come from the L1 cache, because the L1 cache operates at the processor frequency. The moment you have an L1 cache miss and have to go to the L2 cache or to main memory, the processor will stall and potentially sit twiddling its fingers for <emphasis>hundreds</emphasis> of instructions worth of time waiting for a read from main memory to complete. Main memory (the dynamic ram you stuff into a computer) is <emphasis>slow</emphasis>, when compared to the speed of a modern processor core.
Es extremadamente importante... <emphasis>extremadamente</emphasis> importante que la mayoría de accesos a memoria del procesador vengan de la caché L1, porque la caché L1 opera a la frecuencia del procesador. En el momento en el que tienes una pérdida en la caché L1 y tienes que ir a la caché L2 o a la memoria principal, el procesador parará y potencialmente se sentaría a espearr durante un tiempo equivalente a <emphasis>cientos</emphasis> de instrucciones hasta que la lectura de memoria principal se complete. La memoria principal (la memoria dinámica que pones en tu ordenador) es <emphasis>lenta</emphasis>, cuando se compara con la velocidad del procesador.
a month ago
So if I have a 4-way set associative cache I can access offset 0, offset 128K, 256K and offset 384K and still be able to access offset 0 again and have it come from the L1 cache. If I then access offset 512K, however, one of the four previously cached data objects will be thrown away by the cache.
Así que si tenemos una caché de conjuntos asociativa de cuádruple sentido puedo acceder los desplazamientos 0, 128K, 256K y 384K y todavía ser capaz de acceder al desplazamiento 0 de nuevo y que me lo devuelva de la caché L1. Se luego accedo al desplazamiento 512K, sin embargo, uno de loas cuatro objetos de datos cacheados previamente será descartado por la caché.
a month ago
Browse all component changes

Daily activity

Daily activity

Weekly activity

Weekly activity