Translation

(itstool) path: sect2/para
Mutexes in FreeBSD kernel (see <citerefentry><refentrytitle>mutex</refentrytitle><manvolnum>9</manvolnum></citerefentry>) have one distinction from their more common userland cousins — the code cannot sleep while holding a mutex). If the code needs to sleep a lot, <citerefentry><refentrytitle>sx</refentrytitle><manvolnum>9</manvolnum></citerefentry> locks may be more appropriate. On the other hand, if you do almost everything in a single thread, you may get away with no mutexes at all.
524/4900
Context English Spanish State
Now, the notification of bio completion <quote>bubbles up</quote> in the <literal>g_up</literal> thread. First the partition slicer gets <function>.done</function>() called in the <literal>g_up</literal> thread, it uses information stored in the bio to free the cloned <varname remap="structname">bio</varname> structure (with <function>g_destroy_bio</function>()) and calls <function>g_io_deliver</function>() on the original request. Ahora, la notificación de bio <quote>burbujea</quote> en el thread <literal>g_up</literal>. Primero, el slicer de paticiones obtiene <function>.done</function>() llamando al thread <literal>g_up</literal>, utiliza la información almacenada en la bio para liberar la estructura <varname remap="structname">bio</varname> clonada (con <function>g_destroy_bio</function>()) y llama a <function>g_io_deliver</function>() en la solicitud original
The filesystem gets the data and transfers it to userland. El sistema de archivos obtiene los datos y los transfiere al espacio de usuario
See <citerefentry><refentrytitle>g_bio</refentrytitle><manvolnum>9</manvolnum></citerefentry> man page for information how the data is passed back and forth in the <varname remap="structname">bio</varname> structure (note in particular the <varname>bio_parent</varname> and <varname>bio_children</varname> fields and how they are handled). Consulte la página del manual <citerefentry><refentrytitle>g_bio</refentrytitle><manvolnum>9</manvolnum></citerefentry> para obtener información sobre cómo se transfieren los datos en la estructura <varname remap="structname">bio</varname> (en particular, tenga en cuenta los campos <varname>bio_parent</varname> y <varname>bio_children</varname> y cómo se manejan).
One important feature is: <emphasis>THERE CAN BE NO SLEEPING IN G_UP AND G_DOWN THREADS</emphasis>. This means that none of the following things can be done in those threads (the list is of course not complete, but only informative): Una característica importante es: <emphasis>NO SE PUEDE DORMIR (SLEEPING) EN LOS THREADS G_UP Y G_DOWN</emphasis>. Esto significa que no se puede hacer nada de lo siguiente en esos threads (la lista, por supuesto, no está completa, es solo informativa):
Calls to <function>msleep</function>() and <function>tsleep</function>(), obviously. Las llamadas a <function>msleep</function>() y <function>tsleep</function>(), obviamente
Calls to <function>g_write_data</function>() and <function>g_read_data</function>(), because these sleep between passing the data to consumers and returning. Las llamadas a <function>g_write_data</function>() y <function>g_read_data</function>(), porque producen sleep al pasar datos al consumidor y regresar
Waiting for I/O. Esperar E/S
Calls to <citerefentry><refentrytitle>malloc</refentrytitle><manvolnum>9</manvolnum></citerefentry> and <function>uma_zalloc</function>() with <varname>M_WAITOK</varname> flag set Las llamadas a <citerefentry><refentrytitle>malloc</refentrytitle><manvolnum>9</manvolnum></citerefentry> y <function>uma_zalloc</function>() con el flag <varname>M_WAITOK</varname> activo
sx and other sleepable locks sx y otros sleepable locks
This restriction is here to stop GEOM code clogging the I/O request path, since sleeping is usually not time-bound and there can be no guarantees on how long will it take (there are some other, more technical reasons also). It also means that there is not much that can be done in those threads; for example, almost any complex thing requires memory allocation. Fortunately, there is a way out: creating additional kernel threads. Esta restricción está aquí para impedir que el código GEOM obstruya la ruta de las solicitudes de E/S, ya que el sleeping no tiene limite de tiempo y puede no haber garantías sobre cuánto tiempo tardará (también hay algunas otras razones más técnicas). También significa que no hay mucho que se pueda hacer en estos threads; por ejemplo, prácticamente cualquier cosa compleja requiere asignación de memoria. Afortunadamente, hay una salida: crear threads adicionales en el kernel.
Kernel Threads for Use in GEOM Code Threads del kernel para usar en el código GEOM
Kernel threads are created with <citerefentry><refentrytitle>kthread_create</refentrytitle><manvolnum>9</manvolnum></citerefentry> function, and they are sort of similar to userland threads in behavior, only they cannot return to caller to signify termination, but must call <citerefentry><refentrytitle>kthread_exit</refentrytitle><manvolnum>9</manvolnum></citerefentry>. Los threads del kernel se crean con la función <citerefentry><refentrytitle>kthread_create</refentrytitle><manvolnum>9</manvolnum></citerefentry>, y son similares en el comportamiento a los threads del espacio de usuario, solo que no pueden regresar a quien los ha llamado para indicar que han terminado, debe llamar a <citerefentry><refentrytitle>kthread_exit</refentrytitle><manvolnum>9</manvolnum></citerefentry>.
In GEOM code, the usual use of threads is to offload processing of requests from <literal>g_down</literal> thread (the <function>.start</function>() function). These threads look like <quote>event handlers</quote>: they have a linked list of event associated with them (on which events can be posted by various functions in various threads so it must be protected by a mutex), take the events from the list one by one and process them in a big <literal>switch</literal>() statement. En el código GEOM, el uso habitual de los threads es para descargar el procesamiento de peticiones del thread <literal>g_down</literal> (la función <function>.start</function>()). Estos threads parecen <quote>event handlers</quote>: tienen vinculada una lista de eventos asociados a ellos (en los cuales los eventos pueden publicarse mediante varias funciones en varios threads, por lo que deben estar protegidos por un mutex), toma los eventos de la lista, uno por uno, y los procesa en una gran instrucción <literal>switch</literal>().
The main benefit of using a thread to handle I/O requests is that it can sleep when needed. Now, this sounds good, but should be carefully thought out. Sleeping is well and very convenient but can very effectively destroy performance of the geom transformation. Extremely performance-sensitive classes probably should do all the work in <function>.start</function>() function call, taking great care to handle out-of-memory and similar errors. La principal ventaja de utilizar un thread para manejar las solicitudes de E/S es que pueden dormir (sleep) cuando sea necesario. Ahora, esto suena bien, pero se debe pensar cuidadosamente. Dormir(sleeping) es bueno y muy conveniente, pero puede ser muy efectivo destruyendo el rendimiento de la transformación de geom. Las clases extremadamente sensibles al rendimiento probablemente deberían de hacer todo el trabajo en la llamada a la función <function>.start</function>(), teniendo mucho cuidado de manejar los errores de falta de memoria y similares.
The other benefit of having a event-handler thread like that is to serialize all the requests and responses coming from different geom threads into one thread. This is also very convenient but can be slow. In most cases, handling of <function>.done</function>() requests can be left to the <literal>g_up</literal> thread. El otro beneficio de tener un thread que controle eventos como ese es la de serializar todas las peticiones y respuestas que vienen de diferentes threads de geom en un solo thread. Esto es muy conveniente, pero puede ser lento. En la mayoría de los casos, el manejo de peticiones de <function>.done</function>() se puede dejar para el thread <literal>g_up</literal>.
Mutexes in FreeBSD kernel (see <citerefentry><refentrytitle>mutex</refentrytitle><manvolnum>9</manvolnum></citerefentry>) have one distinction from their more common userland cousins — the code cannot sleep while holding a mutex). If the code needs to sleep a lot, <citerefentry><refentrytitle>sx</refentrytitle><manvolnum>9</manvolnum></citerefentry> locks may be more appropriate. On the other hand, if you do almost everything in a single thread, you may get away with no mutexes at all. Los mutexes en el kernel de FreeBSD (vea <citerefentry><refentrytitle>mutex</refentrytitle><manvolnum>9</manvolnum></citerefentry>) tienen una distinción de sus primos más comunes en el espacio de usuario — el código no puede dormir (sleep) mientras mantiene un mutex. Si el código necesita dormir (sleep) mucho, los bloqueos <citerefentry><refentrytitle>sx</refentrytitle><manvolnum>9</manvolnum></citerefentry> pueden ser más apropiados. Por otro lado, si hace casi todo en un solo thread, puede no necesitar usar mutexes.

Loading…

User avatar None

New source string

FreeBSD Doc / articles_geom-classSpanish

New source string a year ago
Browse all component changes

Glossary

English Spanish
No related strings found in the glossary.

Source information

Source string comment
(itstool) path: sect2/para
Source string location
article.translate.xml:801
String age
a year ago
Source string age
a year ago
Translation file
articles/es_ES/geom-class.po, string 149