Unit Instance
Units API.
See the Weblate's Web API documentation for detailed description of the API.
GET /api/units/207430/?format=api
{ "translation": "https://translate-dev.freebsd.org/api/translations/freebsd-doc/articles_vm-design/es/?format=api", "source": [ "The page table optimizations make up the most contentious part of the FreeBSD VM design and they have shown some strain with the advent of serious use of <function>mmap()</function>. I think this is actually a feature of most BSDs though I am not sure when it was first introduced. There are two major optimizations. The first is that hardware page tables do not contain persistent state but instead can be thrown away at any time with only a minor amount of management overhead. The second is that every active page table entry in the system has a governing <literal>pv_entry</literal> structure which is tied into the <literal>vm_page</literal> structure. FreeBSD can simply iterate through those mappings that are known to exist while Linux must check all page tables that <emphasis>might</emphasis> contain a specific mapping to see if it does, which can achieve O(n^2) overhead in certain situations. It is because of this that FreeBSD tends to make better choices on which pages to reuse or swap when memory is stressed, giving it better performance under load. However, FreeBSD requires kernel tuning to accommodate large-shared-address-space situations such as those that can occur in a news system because it may run out of <literal>pv_entry</literal> structures." ], "previous_source": "", "target": [ "Las optimizaciones de la tabla de páginas constituyen la parte más controvertida del diseño de la Memoria Virtual de FreeBSD y ha mostrado cierta tensión con la llegada de uso serio de <function>mmap()</function>. Creo que esto en realidad es una característica de la mayor parte de los BSDS aunque no estoy seguro de cuándo se introdujo por primera vez. Hay dos optimizaciones principales. La primar es que las tablas de páginas hardware no contienen un estado persistente sino que pueden descartarse en cualquier momento con solo un pequeño sobre coste en la gestión. La segunda es que cada entrada en la tabla de páginas activas en el sistema tiene una estructura <literal>pv_entry</literal> que lo gobierna la cual está enlazada a la estructura <literal>vm_page</literal>. FreeBSD puede simplemente iterar sobre esos mapeos que se sabe que existen mientras Linux tiene que comprobar todas las tablas de páginas que <emphasis>podrían</emphasis> contener un mapeo específico para ver si es así, lo que puede provocar un sobre coste de O(n^2) en algunas situaciones. Por esto FreeBSD tiene a tomar mejores decisiones sobre qué páginas reutilizar o intercambiar cuando la memoria está bajo estrés, resultando en un mejor rendimiento bajo carga. Sin embargo, FreeBSD requiere ajustes del núcleo para acomodar situaciones con grandes espacios de direcciones compartidos como los que pueden darse en sistemas nuevos porque podría agotar las estructuras <literal>pv_entry</literal>." ], "id_hash": -794297548351206436, "content_hash": -794297548351206436, "location": "article.translate.xml:547", "context": "", "note": "(itstool) path: sect1/para", "flags": "", "labels": [], "state": 20, "fuzzy": false, "translated": true, "approved": false, "position": 69, "has_suggestion": false, "has_comment": false, "has_failing_check": true, "num_words": 201, "source_unit": "https://translate-dev.freebsd.org/api/units/102108/?format=api", "priority": 100, "id": 207430, "web_url": "https://translate-dev.freebsd.org/translate/freebsd-doc/articles_vm-design/es/?checksum=74fa169690900bdc", "url": "https://translate-dev.freebsd.org/api/units/207430/?format=api", "explanation": "", "extra_flags": "", "pending": false, "timestamp": "2020-11-14T21:36:50.821499Z" }