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

Translation

(itstool) path: listitem/para
English
The most important aspect of performance design is what is known as <quote>Optimizing the Critical Path</quote>. It is often the case that performance optimizations add a little bloat to the code in order to make the critical path perform better.
250/2460 · 246
Context English Spanish State
_ translator-credits Fernando Apesteguía fernape@FreeBSD.org, 2021
Design elements of the FreeBSD VM system Elementos de diseño del sistema de Memoria Virtual de FreeBSD

<email>dillon@apollo.backplane.com</email>
<email>dillon@apollo.backplane.com</email>
<personname><firstname>Matthew</firstname><surname>Dillon</surname></personname><affiliation> <_:address-1/> </affiliation> <personname><firstname>Matthew</firstname><surname>Dillon</surname></personname><affiliation> <_:address-1/> </affiliation>
FreeBSD is a registered trademark of the FreeBSD Foundation. FreeBSD es una marca registrada de la Fundación FreeBSD.
Linux is a registered trademark of Linus Torvalds. Linux es una marca registrada de Linus Torvalds.
Microsoft, IntelliMouse, MS-DOS, Outlook, Windows, Windows Media and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. Microsoft, IntelliMouse, MS-DOS, Outlook, Windows, Windows Media y Windows NT son marcas registradas o marcas de Microsoft Corporation en los Estados Unidos y/o en otros paises.
Motif, OSF/1, and UNIX are registered trademarks and IT DialTone and The Open Group are trademarks of The Open Group in the United States and other countries. Motif, OSF/1, y UNIX son marcas registradas y IT DialTone y The Open Group son marcas de The Open Group en los Estados Unidos y en otros paises.
Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this document, and the FreeBSD Project was aware of the trademark claim, the designations have been followed by the <quote>™</quote> or the <quote>®</quote> symbol. Muchas de las designaciones utilizadas por los fabricantes y vendedores para distinguir sus productos se reclaman como marcas comerciales. Cuando esas designaciones aparecen en este documento, y el Proyecto FreeBSD estaba al tanto del reclamo de marca registrada, las designaciones han sido seguidas por el <quote>™</quote> or the <quote>®</quote> symbol.
$FreeBSD$ $FreeBSD$
The title is really just a fancy way of saying that I am going to attempt to describe the whole VM enchilada, hopefully in a way that everyone can follow. For the last year I have concentrated on a number of major kernel subsystems within FreeBSD, with the VM and Swap subsystems being the most interesting and NFS being <quote>a necessary chore</quote>. I rewrote only small portions of the code. In the VM arena the only major rewrite I have done is to the swap subsystem. Most of my work was cleanup and maintenance, with only moderate code rewriting and no major algorithmic adjustments within the VM subsystem. The bulk of the VM subsystem's theoretical base remains unchanged and a lot of the credit for the modernization effort in the last few years belongs to John Dyson and David Greenman. Not being a historian like Kirk I will not attempt to tag all the various features with peoples names, since I will invariably get it wrong. El título es sólo una forma elegante de decir que voy a intentar describir la enchilada de la Memoria Virtual, espero que de un modo que todo el mundo pueda seguir. Durante el último año me he concentrado en un número de subsistemas principales del kernel de FreeBSD, con los subsistemas de Memoria Virtual e Intercambio siendo los más interesantes y NFS siendo <quote>una tarea necesaria</quote>. Reescribí sólo pequeñas porciones del código. En el área de Memoria Virtual la única reescritura importante que he hecho es el subsistema de intercambio. La mayor parte de mi trabajo fue de limpieza y mantenimiento, con tan sólo reescrituras moderadas de código y sin ajustes algorítimicos importanes en el subsistema de Memoria Virtual. El grueso de la base teórica del subsistema de Memoria Virtual permanece sin cambios y mucho del crédito del esfuerzo de modernización en los últimos años es para John Dyson y David Greenman. Como no soy un historiador como Kirk no intentaré etiquetar todas las características con nombres de personas, ya que me equivocaría irremediablemente.
This article was originally published in the January 2000 issue of <link xlink:href="http://www.daemonnews.org/">DaemonNews</link>. This version of the article may include updates from Matt and other authors to reflect changes in FreeBSD's VM implementation. Este artículo se publicó originalmente en la edición de Enero de 2000 de <link xlink:href="http://www.daemonnews.org/">DaemonNews</link>. Esta versión del artículo puede incluir actualizacione de Matt y otros autores para reflejar los cambios en la implementación de la Memoria Virtual en FreeBSD.
Introduction Introducción
Before moving along to the actual design let's spend a little time on the necessity of maintaining and modernizing any long-living codebase. In the programming world, algorithms tend to be more important than code and it is precisely due to BSD's academic roots that a great deal of attention was paid to algorithm design from the beginning. More attention paid to the design generally leads to a clean and flexible codebase that can be fairly easily modified, extended, or replaced over time. While BSD is considered an <quote>old</quote> operating system by some people, those of us who work on it tend to view it more as a <quote>mature</quote> codebase which has various components modified, extended, or replaced with modern code. It has evolved, and FreeBSD is at the bleeding edge no matter how old some of the code might be. This is an important distinction to make and one that is unfortunately lost to many people. The biggest error a programmer can make is to not learn from history, and this is precisely the error that many other modern operating systems have made. <trademark class="registered">Windows NT</trademark> is the best example of this, and the consequences have been dire. Linux also makes this mistake to some degree—enough that we BSD folk can make small jokes about it every once in a while, anyway. Linux's problem is simply one of a lack of experience and history to compare ideas against, a problem that is easily and rapidly being addressed by the Linux community in the same way it has been addressed in the BSD community—by continuous code development. The <trademark class="registered">Windows NT</trademark> folk, on the other hand, repeatedly make the same mistakes solved by <trademark class="registered">UNIX</trademark> decades ago and then spend years fixing them. Over and over again. They have a severe case of <quote>not designed here</quote> and <quote>we are always right because our marketing department says so</quote>. I have little tolerance for anyone who cannot learn from history. Antes de avanzar con el diseño real dediquemos un poco de tiempo a la necesidad de mantener y modernizar cualquier base de código de larga duración. En el mundo de la programción, los algoritmos tienen a se más importantes que el código y es precisamente debido a las raíces académias de BSD que una gran parte de la atención se puso desde el comienzo en el diseño algorítmico. Prestar más atención al diseño generalmente lleva a una base de código limpio y flexible que puede ser modificado fácilmente, extendido o reemplazado a lo largo del tiempo. Aunque BSD es considerado por alguna gente como un sistema operativo<quote>viejo</quote>, aquellos de nosotros que trabajamos en él solemos verlo más como una base de código</quote>madura</quote> la cual tiene varios componentes modificados, extendidos, o reemplazados con código moderno. Ha evolucionado, y FreeBSD está a la vanguardia independientemente de cómo de viejo sea parte del código. Es impoprtante hacer esta distinción y que mucha gente pasa por alto. El mayor error que puede cometer un programador es no aprender de la historia, y es precisamente este error el que han cometido muchos otros sistemas operativos modernos. <trademark class="registered">Windows NT</trademark> es el mejor ejemplo, y las consecuencias han sido nefastas. Linux también comete este error hasta cierto punto—lo suficiente para que nosotros la gente de BSD hagamos pequeñas bromas de vez en cuando, por lo menos. El problema de Linux es simplemente la falta de experiencia y de una historia contra la que comparar ideas, un problema que está siendo tratado rápidamente por la comunidad Linux de la misma forma que ha sido tratado en la comunidad BSD—mediante el desarrollo continuo de código. La gente de <trademark class="registered">Windows NT</trademark>, por otro lado, repiten los mismos errores solucionados por <trademark class="registered">UNIX</trademark> hace décadas y pasan años arreglándolos. Una y otra vez. Sufren un caso severo de <quote>no diseñado aquí</quote> y <quote>siempre tenemos la razón porque nuestro departamento de marketing así lo dice</quote>. Tengo poca tolerancia hacia cualquiera que no puede aprender de la historia.
Much of the apparent complexity of the FreeBSD design, especially in the VM/Swap subsystem, is a direct result of having to solve serious performance issues that occur under various conditions. These issues are not due to bad algorithmic design but instead rise from environmental factors. In any direct comparison between platforms, these issues become most apparent when system resources begin to get stressed. As I describe FreeBSD's VM/Swap subsystem the reader should always keep two points in mind: Mucha de la aparente complejidad del diseño de FreeBSD, especialmente en el subsistema de Memoria Virtual/Intercambio, es un resultado directo de tener que resolver serios problemas de rendimiento que ocurren bajo condiciones variadas. Estos problemas no se deben aun mal diseño algorítimico sino que surgen de factores ambientales. En cualquier comparación directa entre plataformas, estos problemas se hacen más evidentes cuando los recursos del sistema empiezan a sufrir estrés. Como describo en el subsistema de Memoria Virtual/Intercambio de FreeBSD el lector siempre debería tener en mente dos puntos:
The most important aspect of performance design is what is known as <quote>Optimizing the Critical Path</quote>. It is often the case that performance optimizations add a little bloat to the code in order to make the critical path perform better. El aspecto más importante del diseño de rendimiento es lo que se conoce como <quote>Optimización del Camino Crítico</quote>. Es común que las optimizaciones de rendimiento inflen algo el código con el fin de mejorar el rendimiento del camino crítico.
A solid, generalized design outperforms a heavily-optimized design over the long run. While a generalized design may end up being slower than an heavily-optimized design when they are first implemented, the generalized design tends to be easier to adapt to changing conditions and the heavily-optimized design winds up having to be thrown away. Un diseño sólido, generalizado tiene mejor rendimiento a largo plazo que un diseño altamente optimizado. Mientras que un diseño generalizado puede terminar siendo más lento que un diseño altamente optimizado cuando se implementan inicialmente, el diseño generalizado tiende a ser más fácil de adaptar a condiciones cambiantes y el diseño altamente optimizado termina siendo desechado.
Any codebase that will survive and be maintainable for years must therefore be designed properly from the beginning even if it costs some performance. Twenty years ago people were still arguing that programming in assembly was better than programming in a high-level language because it produced code that was ten times as fast. Today, the fallibility of that argument is obvious — as are the parallels to algorithmic design and code generalization. Cualquier base de código que sobrevivirá y será mantenible durante años debe por lo tanto ser diseñada adecuadamente desde el comienzo incluso si tiene algo de coste en rendimiento. Hace veinte años la gente todavía discutía si la programación en ensamblador era mejor que programar en un lenguaje de alto nivel porque producía código que era diez veces más rápido. Hoy, la falibilidad de ese argumento es obvio — de modo paralelo al diseño algorítmico y la generalización de código.
VM Objects Objetos de Memoria Virtual
The best way to begin describing the FreeBSD VM system is to look at it from the perspective of a user-level process. Each user process sees a single, private, contiguous VM address space containing several types of memory objects. These objects have various characteristics. Program code and program data are effectively a single memory-mapped file (the binary file being run), but program code is read-only while program data is copy-on-write. Program BSS is just memory allocated and filled with zeros on demand, called demand zero page fill. Arbitrary files can be memory-mapped into the address space as well, which is how the shared library mechanism works. Such mappings can require modifications to remain private to the process making them. The fork system call adds an entirely new dimension to the VM management problem on top of the complexity already given. La mejor manera de empezar describiendo el sistema de Memoria Virtual de FreeBSD is mirarlo desde la perspectiva de un proceso de usuario. Cada proceso de usuario ve una espacio de direcciones de Memoria Vritual único, privado y contiguo que contiene diversos tipos de objetos de memoria. Estos objetos tienen diversas características. Código de programa y datos de programa son de forma efectiva un solo fichero mapeado en memoria (el fichero binario que se está ejecutando), pero el código del programa es de solo lectura mientras que los datos de programa son copy-on-write. El BSS del programa es sólo memoria asignada y rellenada con ceros bajo demanda, llamada rellenado de página cero bajo demanda. Ficheros arbitrarios pueden ser mapeados en memoria en el espacio de direcciones también, que es como funciona el mecanismo de librerías compartidas. Dichos mapeos pueden requerir modificaciones para permanecer privados al proceso que los realiza. La llamada al sistema fork añade una nueva dimensión a al problema de la gestión de la Memoria Virtual a añadir a la complejidad ya existente.
A program binary data page (which is a basic copy-on-write page) illustrates the complexity. A program binary contains a preinitialized data section which is initially mapped directly from the program file. When a program is loaded into a process's VM space, this area is initially memory-mapped and backed by the program binary itself, allowing the VM system to free/reuse the page and later load it back in from the binary. The moment a process modifies this data, however, the VM system must make a private copy of the page for that process. Since the private copy has been modified, the VM system may no longer free it, because there is no longer any way to restore it later on. Una página de datos binarios de un programa (que es una página copy-on-write básica) ilustra esta complejidad. Un programa binario contiene una sección de datos preinicializados que es inicialmente mapeado directamente por el fichero del programa. Cuando un programa se carga en el espacio de direcciones de Memoria Virtual del proceso, este área es inicialmente mapeado en memoria y respaldado por el programa binario mismo, permitiendo al sistema de Memoria Virtual liberar/reutilizar la página y después cargarla de nuevo desde el binario. Sin embargo, en el momento en que un proceso modifica estos datos, el sistema de Memoria Virtual debe hacer una copia privada para ese proceso. Puesto que la copia privada ha sido modificada, el sistema de Memoria Virtual podría no ser capaz de liberarla, porque no hay forma de restaurarla posteriormente.
You will notice immediately that what was originally a simple file mapping has become much more complex. Data may be modified on a page-by-page basis whereas the file mapping encompasses many pages at once. The complexity further increases when a process forks. When a process forks, the result is two processes—each with their own private address spaces, including any modifications made by the original process prior to the call to <function>fork()</function>. It would be silly for the VM system to make a complete copy of the data at the time of the <function>fork()</function> because it is quite possible that at least one of the two processes will only need to read from that page from then on, allowing the original page to continue to be used. What was a private page is made copy-on-write again, since each process (parent and child) expects their own personal post-fork modifications to remain private to themselves and not effect the other. Notarás inmediatamente que lo que originalmente era un simple mapeo de un fichero se ha convertido en algo más complejo. Los datos pueden ser modificados página a página mientras que el mapeo de ficheros engloba varias páginas a la vez. La complejidad aumenta más cuando un proceso se bifurca. Cuando un proceso se bifurca, el resultado son dos procesos—cada uno con su propio espacio de direcciones privado que incluye cualquier modificación hecha por el proceso original antes de la llamada a <function>fork()</function>. Sería tonto para el sistema de Memoria Virtual hacer una copia completa de los datos en el momento de llamar a <function>fork()</function> porque es bastante posible que al menos uno de los dos procesos solamente necesite leer de esa página a partir de este momento, permitiendo así que se use la página original. Lo que era una página privada se ha convertido en una página copy-on-write de nuevo, puesto que cada proceso (padre y hijo) espera que sus propias modificaciones personales después del fork permanezcan privadas para ellos y que afecten al otro.
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 recibe 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:
_ external ref='fig1' md5='__failed__' external ref='fig1' md5='__failed__'
+---------------+
| A |
+---------------+ 		+---------------+
| A |
+---------------+
<imageobject> <imagedata fileref="fig1"/> </imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>A picture</phrase> </textobject> <imageobject> <imagedata fileref="fig1"/> </imageobject> <textobject> <_:literallayout-1/> </textobject> <textobject> <phrase>Figura A</phrase> </textobject>
A represents the file—pages may be paged in and out of the file's physical media as necessary. Paging in from the disk is reasonable for a program, but we really do not want to page back out and overwrite the executable. The VM system therefore creates a second layer, B, that will be physically backed by swap space: A representa el fichero—las páginas pueden ser paginadas hacia o desde el medio físico del fichero según sea necesario. Paginar desde el disco es razonable para un programa, pero en realidad no queremos paginar de vuelta y sobrescribir el ejecutable. Por tanto, el sistema de Memoria Virtual crea una segunda capa, B, que estará respaldada físicamente por espacio de intercambio:
_ external ref='fig2' md5='__failed__' external ref='fig2' md5='__failed__'
+---------------+
| B |
+---------------+
| A |
+---------------+ 		+---------------+
| B |
+---------------+
| A |
+---------------+
On the first write to a page after this, a new page is created in B, and its contents are initialized from A. All pages in B can be paged in or out to a swap device. When the program forks, the VM system creates two new object layers—C1 for the parent, and C2 for the child—that rest on top of B: En la primera escritura a una página después de esto, se crea una nueva página en B, y su contenido es inicizalizado desde A. Todas las páginas en B pueden ser paginadas a o desde el dispositivo de intercambio. Cuando el programa bifurca, el sistema de Memoria Virtual crea dos capas de objetos nuevas—C1 para el padre, y C2 para el hijo—que descansan sobre B:
_ external ref='fig3' md5='__failed__' external ref='fig3' md5='__failed__'

Loading…

User avatar fernape

New translation

FreeBSD Doc (Archived) / articles_vm-design — Spanish

The most important aspect of performance design is what is known as <quote>Optimizing the Critical Path</quote>. It is often the case that performance optimizations add a little bloat to the code in order to make the critical path perform better.
El aspecto más importante del diseño de rendimiento es lo que se conoce como <quote>Optimización del Camino Crítico</quote>. Es común que las optimizaciones de rendimiento inflen algo el código con el fin de mejorar el rendimiento del camino crítico.
a month ago
Browse all component changes

Glossary

English Spanish
No related strings found in the glossary.

Source information

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