The translation is temporarily closed for contributions due to maintenance, please come back later.

Translation

(itstool) path: answer/para
English
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.
623/5090 · 509
Context English Spanish State
A COW fault can be either zero-fill or program-data. The mechanism is the same either way because the backing program-data is almost certainly already in the cache. I am indeed lumping the two together. FreeBSD does not pre-COW program data or zero-fill, but it <emphasis>does</emphasis> pre-map pages that exist in its cache. Un fallo COW puede ser de rellenado de ceros o de datos de programa. El mecanismo es el mismo en cualquier caso porque el los datos de respaldo del programa ya estarán en la caché. De hecho estoy mezclando los dos. FreeBSD no hace pre-COW de los datos de programa o de rellenado de ceros, pero <emphasis>sí</emphasis> premapea páginas que existen en la caché.
In your section on page table optimizations, can you give a little more detail about <literal>pv_entry</literal> and <literal>vm_page</literal> (or should vm_page be <literal>vm_pmap</literal>—as in 4.4, cf. pp. 180-181 of McKusick, Bostic, Karel, Quarterman)? Specifically, what kind of operation/reaction would require scanning the mappings? En la sección de optimizaciones de la tabla de páginas, puedes dar algo más de detalle acerca de <literal>pv_entry</literal> y <literal>vm_page</literal> (o debería vm_page ser <literal>vm_pmap</literal>—como en 4.4, cf. pp. 180-181 de McKusick, Bostic, Karel, Quarterman)? Específicamente, ¿qué tipo de operación/reacción requeriría un escaneo de los mapas?
How does Linux do in the case where FreeBSD breaks down (sharing a large file mapping over many processes)? ¿Qué tal lo hace Linux en el caso en el que FreeBSD se desmorona (compartir un mapeo de un fichero grande entre muchos procesos)?
A <literal>vm_page</literal> represents an (object,index#) tuple. A <literal>pv_entry</literal> represents a hardware page table entry (pte). If you have five processes sharing the same physical page, and three of those processes's page tables actually map the page, that page will be represented by a single <literal>vm_page</literal> structure and three <literal>pv_entry</literal> structures. Un <literal>vm_page</literal> representa una tupla (objeto,indice#). Un <literal>pv_entry</literal> representa una entrada de la tabla de páginas hardware (pte). Si tienes cinco procesos compartiendo la misma página física y la tabla de páginas de tres de esos procesos mapean la página, ésta será representada mediante una sola estructura <literal>vm_page</literal> y tres estructuras <literal>pv_entry</literal>.
<literal>pv_entry</literal> structures only represent pages mapped by the MMU (one <literal>pv_entry</literal> represents one pte). This means that when we need to remove all hardware references to a <literal>vm_page</literal> (in order to reuse the page for something else, page it out, clear it, dirty it, and so forth) we can simply scan the linked list of <literal>pv_entry</literal>'s associated with that <literal>vm_page</literal> to remove or modify the pte's from their page tables. Las estructuras <literal>pv_entry</literal> sólo representan páginas mapeadas por la MMU (una <literal>pv_entry</literal> representa una pte). Esto significa que cuando necesitamos eliminar todas las referencias hardware a la <literal>vm_page</literal> (para reutilizar la página para otra cosa, pasarla a disco, borrarla, marcarla como sucia y demás) podemos simplemente escanear la lista enlazada de estructuras <literal>pv_entry</literal> asociadas con esa <literal>vm_page</literal> y eliminar o modificar la pte de sus tablas de páginas.
Under Linux there is no such linked list. In order to remove all the hardware page table mappings for a <literal>vm_page</literal> linux must index into every VM object that <emphasis>might</emphasis> have mapped the page. For example, if you have 50 processes all mapping the same shared library and want to get rid of page X in that library, you need to index into the page table for each of those 50 processes even if only 10 of them have actually mapped the page. So Linux is trading off the simplicity of its design against performance. Many VM algorithms which are O(1) or (small N) under FreeBSD wind up being O(N), O(N^2), or worse under Linux. Since the pte's representing a particular page in an object tend to be at the same offset in all the page tables they are mapped in, reducing the number of accesses into the page tables at the same pte offset will often avoid blowing away the L1 cache line for that offset, which can lead to better performance. En Linux no existe dicha lista enlazada. Para eliminar todos los mapeos de tablas de páginas hardware para una <literal>vm_page</literal> linux debe acceder a cada objeto de Memoria Virtual que <emphasis>podría</emphasis> haber mapeado la página. Por ejemplo, si tienes 50 procesos todos mapeando la misma biblioteca compartida y quieres eliminar la página X de esa biblioteca, necesitas acceder a la tabla de páginas de cada uno de esos 50 procesos incluso si sólo 10 de ellos han mapeado la página. Así que Linux está favoreciendo la simplicidad en el diseño por el rendimiento. Muchos algoritmos de Memoria Virtual que son O(1) o (una N pequeña) en FreeBSD terminan siendo O(N), O(N^2), o peor en Linux. Puesto que los pte que representan una página concreta en un objeto suelen estar en el mismo desplazamiento en todas las tablas de páginas en las que están mapeadas, reducir el número de accesos a las tablas de páginas en el mismo desplazamiento del pte evitará por lo general que se destruya la línea de caché L1 para ese desplazamiento, lo que puede conllevar un mejor rendimiento.
FreeBSD has added complexity (the <literal>pv_entry</literal> scheme) in order to increase performance (to limit page table accesses to <emphasis>only</emphasis> those pte's that need to be modified). FreeBSD tiene más complejidad (el esquema de <literal>pv_entry</literal>) para mejorar el rendimiento (para limitar los accesos a la tabla de páginas <emphasis>sólo</emphasis> a aquellos pte que necesitan ser modificados).
But FreeBSD has a scaling problem that Linux does not in that there are a limited number of <literal>pv_entry</literal> structures and this causes problems when you have massive sharing of data. In this case you may run out of <literal>pv_entry</literal> structures even though there is plenty of free memory available. This can be fixed easily enough by bumping up the number of <literal>pv_entry</literal> structures in the kernel config, but we really need to find a better way to do it. Pero FreeBSD tiene un problema de escalado que Linux no tiene en cuento a que hay un número limitado de estructuras <literal>pv_entry</literal> y esto causa problemas cuando tienes datos masivamente compartidos. En esta caso podrías agotar las estructuras <literal>pv_entry</literal> incluso si hay memoria libre disponible de sobra. Esto se puede solucionar bastante fácilmente aumentando el número de estructuras <literal>pv_entry</literal> en la configuración del núcleo, pero necesitamos encontrar una forma mejor de hacerlo.
In regards to the memory overhead of a page table verses the <literal>pv_entry</literal> scheme: Linux uses <quote>permanent</quote> page tables that are not throw away, but does not need a <literal>pv_entry</literal> for each potentially mapped pte. FreeBSD uses <quote>throw away</quote> page tables but adds in a <literal>pv_entry</literal> structure for each actually-mapped pte. I think memory utilization winds up being about the same, giving FreeBSD an algorithmic advantage with its ability to throw away page tables at will with very low overhead. Respecto a la sobrecarga de memoria de una tabla de páginas versus el esquema de <literal>pv_entry</literal>: Linux utiliza tablas de páginas <quote>permanentes</quote> que no se descartan, pero no necesita una <literal>pv_entry</literal> para cada pte potencialmente mapeado. FreeBSD utiliza tablas de páginas <quote>desechables</quote> pero añade una estructura <literal>pv_entry</literal> para cada pte que esté realmente mapeado. Creo que la utilización de memoria termina siendo la misma, dándole a FreeBSD una ventaja algorítmica con su habilidad para desechar tablas de páginas a voluntad con muy poca sobrecarga.
Finally, in the page coloring section, it might help to have a little more description of what you mean here. I did not quite follow it. Por último, en la sección de coloreado de páginas, podría ayudar describir un poco más a lo que te refieres. No lo seguí del todo.
Do you know how an L1 hardware memory cache works? I will explain: Consider a machine with 16MB of main memory but only 128K of L1 cache. Generally the way this cache works is that each 128K block of main memory uses the <emphasis>same</emphasis> 128K of cache. If you access offset 0 in main memory and then offset 128K in main memory you can wind up throwing away the cached data you read from offset 0! ¿Sabes cómo funciona una memoria caché hardware L1? Lo explicaré: Imagina una máquina con 16MB de memoria principal pero sólo 128K de caché L1. Normalmente esta caché funciona de modo que cada bloque de 128K de memoria principal utiliza <emphasis>los mismos</emphasis> 128K de caché. Si accedes al desplazamiento 0 en memoria principal y luego al desplazamiento 128L en memoria principal ¡terminas descartando los datos cacheados que leíste del desplazamiento 0!
Now, I am simplifying things greatly. What I just described is what is called a <quote>direct mapped</quote> hardware memory cache. Most modern caches are what are called 2-way-set-associative or 4-way-set-associative caches. The set-associatively allows you to access up to N different memory regions that overlap the same cache memory without destroying the previously cached data. But only N. Ahora bien, esto simplificando mucho las cosas. Lo que he descrito es lo que se llama una caché de memoria hardware de <quote>mapeo directo</quote>. La mayoría de cachés modernas son lo que se llaman cachés asociativas de conjuntos de doble sentido o cachés asociativas de conjuntos de cuádruple sentido. La asociación por conjuntos te permite acceder hasta N regiones de memoria distinas que se solapan en la misma memoria de caché sin destruir los datos cacheados previamente. Pero sólo N.
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é.
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.
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 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.
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 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).
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.
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é.

Loading…

User avatar fernape

New translation

FreeBSD Doc / articles_vm-design — Spanish

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
Browse all component changes

Glossary

English Spanish
trademark marca comercial FreeBSD Doc

Source information

Source string comment
(itstool) path: answer/para
Source string location
article.translate.xml:869
String age
3 months ago
Source string age
a year ago
Translation file
articles/es/vm-design.po, string 105