Lines Matching refs:en
23 traducción, la única referencia válida es la documentación oficial en
35 consistencia de memoria formal y documentación en tools/memory-model/. Sin
37 sus maintainers en lugar de que como un oráculo infalible.
44 (1) especificar la funcionalidad mínima en la que se puede confiar para
45 cualquier barrera en concreto, y
49 Tenga en cuenta que una arquitectura puede proporcionar más que el
50 requisito mínimo para cualquier barrera en particular, pero si la
53 Tenga en cuenta también que es posible que una barrera no valga (sea no-op)
54 para alguna arquitectura porque por la forma en que funcione dicha
55 arquitectura, la barrera explícita resulte innecesaria en ese caso.
153 relajado, y una CPU en realidad puede realizar las operaciones de memoria
154 en el orden que desee, siempre que la causalidad del programa parezca
156 instrucciones que emite en el orden que quiera, siempre que no afecte al
159 Entonces, en el diagrama anterior, los efectos de las operaciones de
172 El conjunto de accesos visto por el sistema de memoria en el medio se puede
173 organizar en 24 combinaciones diferentes (donde LOAD es cargar y STORE es
186 y por lo tanto puede resultar en cuatro combinaciones diferentes de
195 ser percibidos por los loads realizados por otra CPU en el mismo orden en
206 Aquí hay una dependencia obvia de la dirección, ya que el valor cargado en
207 D depende en la dirección recuperada de P por la CPU 2. Al final de la
214 Tenga en cuenta que la CPU 2 nunca intentará cargar C en D porque la CPU
215 cargará P en Q antes de emitir la carga de *Q.
221 de ubicaciones de memoria, pero el orden en que se accede a los registros
235 el segundo de las cuales casi con certeza resultará en mal funcionamiento,
245 emitirán en orden, con respeto a sí mismo. Esto significa que para:
254 y siempre en ese orden. Sin embargo, en DEC Alpha, READ_ONCE() también
260 Ya sea en DEC Alpha o no, READ_ONCE() también evita que el compilador
263 (*) Los loads y stores superpuestos dentro de una CPU en particular
289 de transformaciones "creativas", que se tratan en la sección BARRERA
293 en el orden dado. Esto significa que para:
334 (*) Incluso en los casos en que los campos de bits están protegidos por
335 cerrojos (o "cerrojos", o "locks"), todos los componentes en un campo
336 de bits dado deben estar protegidos por un candado. Si dos campos en un
348 bytes para "long", en sistemas de 32 y 64 bits, respectivamente. Tenga
349 en cuenta que estos garantías se introdujeron en el estándar C11, así
364 bits están en ubicaciones de memoria separadas. Lo mismo sucede con
369 simultáneamente dos campos de bits en la misma estructura si entre
379 realizan de manera efectiva en orden aleatorio, pero esto puede ser un
388 Tal cumplimiento es importante porque las CPUs y otros dispositivos en un
392 varios tipos de almacenamiento en caché. Las barreras de memoria se
400 Las barreras de memoria vienen en cuatro variedades básicas:
410 Una barrera de escritura es un orden parcial solo en los stores; No
418 [!] Tenga en cuenta que las barreras de escritura normalmente deben
434 Una barrera de dependencia de direcciones es una ordenación parcial en
436 ningún efecto en los stores, ya sean cargas de memoria o cargas
439 Como se mencionó en (1), las otras CPU en el sistema pueden verse como
440 secuencias de stores en el sistema de memoria que la considerada CPU
442 la CPU en cuestión garantiza que para cualquier carga que la preceda,
444 en el momento en que la barrera se complete, los efectos de todos los
451 [!] Tenga en cuenta que la primera carga realmente tiene que tener una
454 dependencia es a través de un condicional en lugar de -en realidad-
455 cargando la dirección en sí, entonces es una dependencia de _control_
459 [!] Tenga en cuenta que las barreras de dependencia de dirección
464 de memoria de direcciones explícitas. Hoy en día, las APIs para marcar
477 Una barrera de lectura es un orden parcial solo en cargas; no es
478 necesario que tenga ningún efecto en los stores.
483 [!] Tenga en mente que las barreras de lectura normalmente deben
495 Una barrera de memoria general es un orden parcial tanto en
535 RELEASE en esa misma variable están garantizados como visibles. En
544 Un subconjunto de las operaciones atómicas descritas en atomic_t.txt
553 garantizar que no habrá tal interacción en ninguna pieza de código en
554 particular, entonces las barreras de memoria son innecesarias en ese
557 Tenga en cuenta que estas son las garantías _mínimas_. Diferentes
559 puede confiar en estas fuera de esa arquitectura en específico.
571 que la barrera dibuja una línea en la cola de acceso del CPU que no
574 (*) No hay garantía de que la emisión de una barrera de memoria en una CPU
575 tenga cualquier efecto directo en otra CPU o cualquier otro hardware
576 en el sistema. El efecto indirecto será el orden en que la segunda CPU
590 en orden.
604 necesitan prestar atención a esta sección son aquellas que trabajan en el
605 código específico de la arquitectura DEC Alpha y aquellas que trabajan en
610 [!] Si bien las dependencias de direcciones se observan tanto en carga a
611 carga como en relaciones de carga a store, las barreras de dependencia de
641 Si bien esto puede parecer una falla en el mantenimiento de la coherencia
642 o la causalidad, no lo es, y este comportamiento se puede observar en
662 [!] Tenga en cuenta que esta situación extremadamente contraria a la
663 intuición surge más fácilmente en máquinas con cachés divididos, de modo
665 banco procesa líneas impares de caché. El puntero P podría almacenarse en
666 una línea de caché impar y la variable B podría almacenarse en una línea de
679 y romper dependencias en muchas formas altamente creativas.
691 para ordenar la lectura en Q con el load en *Q. En otras palabras, este
697 Tenga en cuenta que este patrón debe ser raro. Después de todo, el objetivo
698 del orden de dependencia es -prevenir- escrituras en la estructura de
705 Tenga en cuenta que el orden proporcionado por una dependencia de dirección
711 RCU, por ejemplo. Vea rcu_assign_pointer() y rcu_dereference() en
751 provisto para dependencias de control de load-store, como en el siguiente
760 barreras. Dicho esto, tenga en cuenta que ni READ_ONCE() ni WRITE_ONCE()
764 puede dar lugar a efectos en el orden muy contrarios a la intuición.
775 Es tentador tratar de hacer cumplir el orden en stores idénticos en ambos
790 siguiente manera en casos de alto nivel de optimización:
794 WRITE_ONCE(b, 1); /* BUG: No hay orden en load de a!!! */
804 significa que la CPU está en su derecho de reordenarlos: El condicional es
805 absolutamente necesario y debe estar presente en el código ensamblador
807 compilador. Por lo tanto, si necesita ordenar en este ejemplo, necesita
850 a cero, en cuyo caso el compilador tiene derecho a transformar el código
851 anterior en el siguiente:
860 barrera no lo traerá de vuelta. Por lo tanto, si confia en este orden, debe
873 Tenga en cuenta una vez más que los stores de 'b' difieren. Si fueran
877 También debe tener cuidado de no confiar demasiado en el cortocircuito
897 la cláusula else de la sentencia if en cuestión. En particular, no se
910 en 'b' con la condición. Desafortunadamente para esta línea de
911 razonamiento, el compilador podría compilar las dos escrituras en 'b' como
912 instrucciones de movimiento condicional, como en este fantástico idioma
925 resumen, las dependencias de control se aplican solo a los stores en la
926 cláusula then y la cláusula else de la sentencia if en cuestión (incluidas
931 Tenga muy en cuenta que el orden proporcionado por una dependencia de
942 orden, use smp_rmb(), smp_wmb() o, en el caso de stores anteriores y
948 smp_store_release() para realizar el store. Tenga en cuenta que -no-
950 declaración "if" porque, como se muestra en el ejemplo anterior, la
954 (*) Las dependencias de control requieren al menos un condicional en
1037 [!] Tenga en cuenta que normalmente se esperaría que los stores antes de la
1053 En primer lugar, las barreras de escritura actúan como orden parcial en las
1066 de memoria en un orden que el resto del sistema podría percibir como el
1105 Sin intervención, la CPU 2 puede percibir los eventos en la CPU 1 en orden
1112 | | : +------+ \ +-------+ | percepción en CPU 2
1140 la carga de C y la carga de *C (es decir: B) en la CPU 2:
1180 Y en tercer lugar, una barrera de lectura actúa como un orden parcial sobre
1192 Sin intervención, la CPU 2 puede elegir percibir los eventos en la CPU 1 en
1217 carga de A en la CPU 2:
1318 la carga de B resultó en B == 2. No existe tal garantía para la primera
1326 un elemento de la memoria, y encuentran un momento en el que no están
1327 usando el bus para ningún otra carga, y también en la carga por adelantado,
1328 aunque en realidad no lo hayan llegado a ese punto en el flujo de ejecución
1333 Puede resultar que la CPU en realidad no necesitara el valor, tal vez
1334 porque una condición eludió la carga, en cuyo caso puede descartar el valor
1335 o simplemente almacenar en caché para su uso posterior.
1343 DIVIDE } tardan mucho en terminar
1377 obligará a reconsiderar cualquier valor obtenido especulativamente en una
1379 cambio en la ubicación de memoria especulada, entonces el valor especulado
1428 todos las CPU o, alternativamente, que todas las CPU acuerdan el orden en
1432 multicopia'' en cambio, solo garantiza que un store dado se vuelva visible
1433 al mismo tiempo en todas las -otras- CPUs. El resto de este documento
1446 Suponga que la carga de la CPU 2 desde X devuelve 1, que luego almacena en
1454 Debido a que la carga de la CPU 3 desde X en cierto sentido viene después
1457 si una carga que se ejecuta en la CPU B sigue una carga de la misma
1458 variable que se ejecuta en la CPU A (y la CPU A no almacenó originalmente
1459 el valor que leyó), entonces en sistemas atómicos multicopia, la carga de
1464 El uso de una barrera de memoria general en el ejemplo anterior compensa
1482 Esta sustitución permite que la atomicidad no multicopia se desenfrene: en
1489 este ejemplo se ejecuta en un sistema atómico no multicopia donde las CPU 1
1500 que las CPU de la cadena estén de acuerdo en el orden combinado de los
1501 accesos. Por ejemplo, cambiando a código C en deferencia al fantasma de
1534 Dado que cpu0(), cpu1() y cpu2() participan en una cadena de parejas
1547 liberación-adquisición es local a las CPU que participan en esa cadena y no
1558 en orden, las CPU que no participan en la cadena de liberación-adquisición
1559 pueden estar en desacuerdo con el orden. Este desacuerdo se debe al hecho
1562 ordenar stores anteriores contra cargas posteriores en todos los casos.
1565 acuerdo en que estas dos operaciones ocurrieron en el orden previsto.
1567 Sin embargo, tenga en cuenta que smp_load_acquire() no es mágico. En
1568 particular, simplemente lee de su argumento en orden. Es decir, -no-
1569 asegura que se leerá cualquier valor en particular. Por lo tanto, los
1574 Tenga en cuenta que este resultado puede ocurrir incluso en un mítico
1575 sistema, consistente en secuencia, donde nunca se reordena nada.
1578 operaciones, utilice barreras generales en todo momento.
1616 variables utilizadas en ese loop condicional en cada paso a través de
1620 de optimizaciones que, si bien son perfectamente seguras en código de un
1621 solo subproceso, pueden resultar fatales en código concurrente. Aquí hay
1624 (*) El compilador está en su derecho de reordenar cargas y stores de la
1625 misma variable, y en algunos casos, la CPU está dentro de su
1632 Podría resultar en un valor más antiguo de x almacenado en a[1] que en
1649 en el siguiente código, que, aunque en cierto sentido es legítimo
1663 en los casos en que la alta presión de los registros impida que el
1664 compilador mantenga todos los datos de interés en registros. El
1671 Esto podría resultar en el siguiente código, que es perfectamente
1672 seguro en código de subproceso único, pero puede ser fatal en código
1678 Por ejemplo, la versión optimizada de este código podría resultar en
1679 pasar un cero a hacer_algo_con() en el caso de que la variable a sea
1688 Tenga en cuenta que si el compilador se queda sin registros, podría
1689 guardar tmp en la pila ("stack"). El overhead (coste en eficiencia) de
1695 (*) El compilador está en su derecho de omitir una carga por completo si
1717 Pero, por favor, tenga en cuenta que el compilador también está
1795 Tenga en cuenta que los envoltorios ("wrappers") READ_ONCE() y
1796 WRITE_ONCE() en controlador_interrupcion() son necesarios si este
1800 necesarios en controlador_interrupcion() aparte de con fines de
1801 documentación. (Tenga también en cuenta que las interrupciones
1802 anidadas no ocurren típicamente en los kernels Linux modernos, de
1815 actualmente almacenadas en caché, en cualquier registro de la máquina.
1816 Por supuesto, el compilador también debe respetar el orden en que
1821 como en el siguiente ejemplo:
1836 también ahorra un branch. Desafortunadamente, en código concurrente,
1855 tearing), en el que un solo gran acceso es reemplazado por múltiples
1864 Tenga en cuenta que GCC realmente usa este tipo de optimización, lo
1867 tanto, esta optimización puede ser una victoria en un código de un
1869 hizo que GCC usara incorrectamente esta optimización en un store
1871 desgarro del store en el siguiente ejemplo:
1886 hay markings volátiles, el compilador estaría en su derecho de
1889 resultaría en una carga con desgarro en 'foo1.b' y store del desgarro
1890 en 'foo2.b'. READ_ONCE() y WRITE_ONCE() nuevamente evitan el desgarro
1891 en este ejemplo:
1897 Aparte de esto, nunca es necesario usar READ_ONCE() y WRITE_ONCE() en una
1904 Tenga en cuenta que estas barreras del compilador no tienen un efecto
1905 directo en la CPU, que luego puede reordenar las cosas como quiera.
1925 Además: en el caso de las dependencias de direcciones, se esperaría que el
1926 compilador emita las cargas en el orden correcto (por ejemplo, `a[b]`
1928 garantía alguna en la especificación de C sobre que el compilador no puede
1942 [!] Tenga en cuenta que las barreras de memoria SMP _deben_ usarse para
1943 controlar el orden de referencias a memoria compartida en sistemas SMP,
1944 aunque el uso de bloqueo en su lugar sea suficiente.
1947 SMP, ya que dichas barreras imponen una sobrecarga innecesaria en los
1949 MMIO en los accesos a través de ventanas E/S de memoria relajada. Estas
1950 barreras son necesarias incluso en sistemas que no son SMP, ya que afectan
1951 al orden en que las operaciones de memoria aparecen en un dispositivo, al
1961 barrera del compilador en una compilación UP.
1985 Esto asegura que la marca de muerte en el objeto se perciba como
2026 permite garantizar que los datos se escriben en el descriptor antes de
2028 implica tanto un dma_rmb() como un dma_wmb(). Tenga en cuenta que, al
2042 para los que las modificaciones se escriben en el almacenamiento
2045 Por ejemplo, después de una escritura no temporal en la región pmem,
2063 espera tenga implicaciones en el rendimiento.
2069 Algunas de las otras funciones en el kernel Linux implican barreras de
2075 confiar en estas fuera de código específico de arquitectura.
2083 (*) spin locks (cerrojos en loop)
2124 cerrojo estuviera disponible. Los fallos en cerrojos no implican
2127 [!] Nota: una de las consecuencias de que los cerrojos en ACQUIRE y RELEASE
2179 desbloqueo precede al bloqueo en el código ensamblador. La CPU
2184 operación de bloqueo en el código ensamblador), lo que desenmascará el
2193 primitiva de bloqueo necesita resolver tales carreras correctamente en
2197 garantía de orden en sistemas compilados en UP, por lo que no se puede
2198 contar con tal situación para lograr realmente nada en absoluto,
2220 [+] Tenga en cuenta que {*F,*A} indica un acceso combinado.
2237 barreras en tal situación, deben ser provistas por algún otro medio.
2243 Dormir y despertar son eventos marcados ("flagged") en los datos globales
2247 suceder en el orden correcto, las primitivas para comenzar el proceso de ir
2278 establecer el estado. Toda la secuencia anterior está disponible en varias
2279 formas, todas las cuales obtienen la barrera de memoria en el lugar
2305 no debe confiar en ello. La barrera se produce antes del acceso al estado
2338 particular, si wake_up(), en el fragmento anterior, fuera reemplazado por
2362 [!] Tenga en cuenta que las barreras de la memoria implicadas por el
2381 circunstancia, el código en ambos lados debe sacar sus propias barreras de
2411 sustancial de barrera: una que afecta el orden de acceso a la memoria en
2412 otras CPU, dentro del contexto de conflicto en cualquier bloqueo en
2431 Entonces no hay garantía sobre en qué orden verá la CPU 3 los accesos a *A
2433 separados en las distintas CPUs. Podría, por ejemplo, ver:
2451 incluso si está en un kernel SMP. Existen, sin embargo, cuatro
2452 circunstancias en las que reordenar definitivamente _podría_ ser un
2467 Cuando se da un sistema con más de un procesador, más de una CPU en el
2468 sistema puede estar trabajando en el mismo conjunto de datos al mismo
2477 de espera en cola del semáforo, en virtud de que tiene una parte de su pila
2478 vinculada a la lista de procesos en espera del semáforo:
2491 Para despertar a un proceso que espera ("waiter") en particular, las
2502 (4) llamar a wake_up_process() en la tarea; y
2504 (5) liberar la referencia retenida en la estructura de tareas del waiter.
2517 Una vez que se ha puesto en cola y soltado el bloqueo de semáforo, el
2518 proceso que espera no consigue el candado de nuevo; en cambio, solo espera
2520 está en la pila del proceso que espera, esto significa que si el puntero de
2532 Poner waiter en la "queue" (cola)
2563 que todos los accesos a memoria antes de la barrera se completarán en el
2564 momento en que la instrucción de la barrera en sí se complete.
2568 emita las instrucciones en el orden correcto sin realmente intervenir en la
2579 pero se confía mucho en ellos en su conjunto a lo largo del kernel.
2591 Esto puede aliviarse, al menos en parte, desactivando las interrupciones
2593 todas contenidas dentro la sección de interrupción desactivada en el
2595 es posible que el "core" del controlador no se ejecute en la misma CPU y no
2602 el core de ese controlador habla con la tarjeta estando en desactivación de
2615 El almacenamiento en el registro de datos puede ocurrir después del segundo
2616 almacenamiento en el registro de direcciones si las reglas de orden son lo
2623 filtrarse fuera de esta y pueden intercalarse con accesos realizados en una
2628 dentro de tales secciones incluirán operaciones de carga síncronas en
2634 rutinas ejecutándose en separadas CPU que se comunican entre sí. Si tal
2661 mismo subproceso de la CPU a un dispositivo en particular llegarán en
2667 mismo spinlock. Esto garantiza que ese registro MMIO escribe en un
2668 dispositivo en particular, mientras que se obtiene un spinlock en un
2672 a la finalización de todas las escrituras anteriores en la memoria
2676 cuando la CPU escriba en sus registros de control MMIO, para activar
2689 comenzar a ejecutarse en el mismo subproceso. Esto asegura que dos
2690 escrituras del CPU a registros MMIO en un periférico llegarán al menos
2713 al mismo periférico, cuando se opera en punteros __iomem asignados con el
2719 acceder FIFOs mapeados en memoria y basados en registros que residen en
2728 instrucciones especiales en algunas arquitecturas (especialmente, en
2759 bytes en arquitecturas big-endian.
2773 instrucciones en el orden que se quiera - o incluso en paralelo - siempre
2774 que si una instrucción en el flujo depende de una instrucción anterior,
2776 antes de que la posterior instrucción puede proceder; en otras palabras:
2785 adyacentes cargan un valor inmediato en el mismo registro, la primera puede
2798 La forma en que se perciben las operaciones de memoria caché en todo el
2800 encuentran entre las CPU y la memoria, y por el sistema de coherencia en
2801 memoria que mantiene la consistencia de estado en el sistema.
2803 En cuanto a la forma en que una CPU interactúa con otra parte del sistema a
2805 CPU y barreras de memoria, que en su mayor parte actúan en la interfaz
2807 la línea de puntos en el siguiente diagrama):
2831 Aunque es posible que una carga o store en particular no aparezca fuera de
2836 propagarán los efectos en caso de conflicto.
2838 El núcleo de la CPU puede ejecutar instrucciones en el orden que considere
2842 núcleo puede colocarlos en la cola en cualquier orden que desee, y
2846 De lo que se ocupan las barreras de la memoria es de controlar el orden en
2848 y el orden en que los otros observadores perciben los efectos en el sistema
2853 hubieran sucedido en el orden del programa.
2868 "sucias" pueden residir en los cachés de varias CPU, y es posible que no
2869 se hayan vuelto a escribir en la RAM todavía. Para hacer frente a esto, la
2870 parte apropiada del kernel debe vaciar los bits superpuestos de caché en
2874 sobrescritos por líneas de caché sucias que se escriben de nuevo en la RAM
2876 propios datos, o las líneas de caché presentes en el caché de la CPU pueden
2878 hasta el momento en que la caché se descarta de la memoria caché de la CPU
2880 kernel debe invalidar los bits superpuestos del caché en cada CPU.
2889 La E/S mapeada en memoria generalmente se lleva a cabo a través de
2895 eluden el almacenamiento en caché por completo e ir directamente a los
2896 buses del dispositivo. Esto significa que los accesos MMIO pueden, en
2898 anteriormente. Una barrera de memoria no es suficiente en tal caso, sino
2908 de memoria exactamente en el orden especificado, de modo que si a la CPU se
2919 secuencia de operaciones vistas por observadores externos en el sistema:
2927 permitir progreso en la ejecución, mientras que los stores a menudo se
2934 se haya obtenido el resultado en el momento equivocado de la secuencia
2949 coherencia se propague en orden a otras CPU.
2951 Entonces, digamos que lo que otra CPU podría observar en el fragmento de
2983 en ese orden, pero, sin intervención, la secuencia puede contener casi
2985 perspectiva del programa del mundo siga siendo consistente. Tenga en cuenta
2986 que READ_ONCE() y WRITE_ONCE() -no- son opcionales en el ejemplo anterior,
2988 sucesivas en la misma ubicación. En tales arquitecturas, READ_ONCE() y
2989 WRITE_ONCE() hacen lo que sea necesario para evitar esto, por ejemplo, en
3027 actualizadas en momentos separados. Aquí es donde la barrera de dependencia
3030 cambio en el puntero, frente a que los nuevos datos se produzcan en el
3034 v4.15, la adición al kernel de Linux de smp_mb() a READ_ONCE() en Alpha
3035 redujo en gran medida su impacto en el modelo de memoria.
3041 Los "guests" (invitados) que se ejecutan en máquinas virtuales pueden verse
3042 afectados por los efectos de SMP incluso si el "host" (huésped) en sí se
3051 virt_mb() en lugar de smp_mb() al sincronizar contra un (posiblemente SMP)
3054 Estos son equivalentes a sus contrapartes smp_mb() etc. en todos los demás
3055 aspectos, en particular, no controlan los efectos MMIO: para controlar los
3067 en búfer circular, sin necesidad de un cerrojo para serializar al productor