Lines Matching refs:el
49 Tenga en cuenta que una arquitectura puede proporcionar más que el
112 - Y luego está el Alfa.
126 Considere el siguiente modelo abstracto del sistema:
152 En la CPU abstracta, el orden de las operaciones de memoria es muy
154 en el orden que desee, siempre que la causalidad del programa parezca
155 mantenerse. De manera similar, el compilador también puede organizar las
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
160 memoria realizadas por un CPU son percibidos por el resto del sistema a
161 medida que las operaciones cruzan la interfaz entre la CPU y el resto del
172 El conjunto de accesos visto por el sistema de memoria en el medio se puede
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
221 de ubicaciones de memoria, pero el orden en que se accede a los registros
224 puerto de dirección (A) y un registro de datos del puerto (D). Para leer el
225 registro interno 5, el siguiente código podría entonces ser usado:
235 el segundo de las cuales casi con certeza resultará en mal funcionamiento,
236 ya que se estableció la dirección _después_ de intentar leer el registro.
260 Ya sea en DEC Alpha o no, READ_ONCE() también evita que el compilador
286 (*) _No_debe_ asumirse que el compilador hará lo que usted quiera
288 WRITE ONCE(). Sin ellos, el compilador tiene derecho a hacer todo tipo
293 en el orden dado. Esto significa que para:
339 pueden causar una actualización a una campo para corromper el valor de
349 en cuenta que estos garantías se introdujeron en el estándar C11, así
366 estructura anidada y el otro no, o si las dos están separados por una
371 cuál resulta ser el tamaño de estos campos de bits intermedios.
382 CPU para restringir el orden.
389 sistema pueden usar una variedad de trucos para mejorar el rendimiento,
390 incluido el reordenamiento, diferimiento y combinación de operaciones de
393 utilizan para anular o suprimir estos trucos, permitiendo que el código
414 store al sistema de memoria a medida que pasa el tiempo. Todos los
427 barrera de lectura. En el caso de que se realicen dos loads de manera
428 que la segunda dependa del resultado de la primera (por ejemplo: el
429 primer load recupera la dirección a la que se dirigirá el segundo
431 asegurarse de que el objetivo de la segunda carga esté actualizado
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
444 en el momento en que la barrera se complete, los efectos de todos los
463 [!] Desde el kernel v5.9, se eliminó la API del kernel para barreras
576 en el sistema. El efecto indirecto será el orden en que la segunda CPU
578 el siguiente argumento:
580 (*) No hay garantía de que una CPU vea el orden correcto de los efectos
583 barrera de memoria coincidente (vea el subapartado "Emparejamiento de
604 necesitan prestar atención a esta sección son aquellas que trabajan en el
641 Si bien esto puede parecer una falla en el mantenimiento de la coherencia
646 de dirección implícita desde el lanzamiento del kernel v4.15:
664 que, por ejemplo, un banco de caché procesa líneas de caché pares y el otro
667 caché con número par. Entonces, si el banco de números pares de la memoria
668 caché de la CPU de lectura está extremadamente ocupado mientras que el
669 banco impar está inactivo, uno podría ver el nuevo valor del puntero P
670 (&B), pero el antiguo valor de la variable B (2).
674 escrituras dependientes porque las CPU que admite el kernel Linux no
677 Pero, por favor, lea atentamente la sección "DEPENDENCIAS DEL CONTROL" y el
678 archivo Documentation/RCU/rcu_dereference.rst: el compilador puede romperse
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
701 de error y similares, y el orden natural de las CPUs evita que se pierdan
705 Tenga en cuenta que el orden proporcionado por una dependencia de dirección
710 La barrera de dependencia de dirección es muy importante para el sistema
712 include/linux/rcupdate.h. Esto permite que el objetivo actual de un puntero
713 RCU sea reemplazado con un nuevo objetivo modificado, sin que el objetivo
729 Considere el siguiente fragmento de código:
738 Esto no tendrá el efecto deseado porque no hay una dependencia de dirección
740 cortocircuitar al intentar predecir el resultado por adelantado, para que
751 provisto para dependencias de control de load-store, como en el siguiente
761 son opcionales! Sin READ_ONCE(), el compilador podría combinar la carga de
762 'a' con otras cargas de 'a'. Sin WRITE_ONCE(), el compilador podría
763 combinar el store de 'b' con otros stores de 'b'. Cualquiera de estos casos
764 puede dar lugar a efectos en el orden muy contrarios a la intuición.
766 Peor aún, si el compilador puede probar (decir) que el valor de la
768 para optimizar el ejemplo original eliminando la declaración "if", como:
775 Es tentador tratar de hacer cumplir el orden en stores idénticos en ambos
803 Ahora no hay condicional entre la carga de 'a' y el store de 'b', lo que
805 absolutamente necesario y debe estar presente en el código ensamblador
820 Por el contrario, sin barreras de memoria explícita, el control de un if
833 Aún se requiere el inicial READ_ONCE() para evitar que el compilador toque
834 el valor de 'a'.
837 contrario, el compilador podría adivinar el valor y volver a eliminar el
849 Si MAX se define como 1, entonces el compilador sabe que (q % MAX) es igual
850 a cero, en cuyo caso el compilador tiene derecho a transformar el código
851 anterior en el siguiente:
857 Dada esta transformación, la CPU no está obligada a respetar el orden entre
858 la carga de la variable 'a' y el store de la variable 'b'. Es tentador
874 idénticos, como se señaló anteriormente, el compilador podría sacar ese
877 También debe tener cuidado de no confiar demasiado en el cortocircuito
885 siempre cierta, el compilador puede transformar este ejemplo de la
891 Este ejemplo subraya la necesidad de asegurarse de que el compilador no
908 Es tentador argumentar que, de hecho, existe un orden porque el compilador
911 razonamiento, el compilador podría compilar las dos escrituras en 'b' como
923 carga de 'a' y el store de 'c'. Las dependencias de control se extenderían
924 solo al par de instrucciones cmov y el store dependiente de ellas. En
931 Tenga muy en cuenta que el orden proporcionado por una dependencia de
932 control es local a la CPU que lo contiene. Vea el apartado de "Atomicidad
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
955 tiempo de ejecución entre la carga anterior y el almacenamiento
956 posterior, y este condicional debe implicar la carga previa. Si el
957 compilador es capaz de optimizar el condicional y quitarlo, también
958 habrá optimizado el ordenar. El uso cuidadoso de READ_ONCE() y
959 WRITE_ONCE() puede ayudar a preservar el necesario condicional.
961 (*) Las dependencias de control requieren que el compilador evite
1065 Esta secuencia de eventos es finalizado para con el sistema de coherencia
1066 de memoria en un orden que el resto del sistema podría percibir como el
1075 | | : | A=1 | } \/ el resto del sistema
1130 el mantenimiento de \ +-------+ | |
1136 En el ejemplo anterior, la CPU 2 percibe que B es 7, a pesar de la carga de
1229 entonces el orden parcial impuesto por la CPU 1 será percibido
1253 el código contenía una carga de A a cada lado de la barrera de lectura:
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
1330 potencialmente complete de inmediato, porque la CPU ya tiene el valor a
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
1355 especula sobre el LOAD de A +-------+ ~ | |
1360 la CPU puede realizar el : : | |
1379 cambio en la ubicación de memoria especulada, entonces el valor especulado
1389 especula sobre el LOAD de A +-------+ ~ | |
1402 entonces la especulación será cancelada y el valor recargado:
1411 especula sobre el LOAD de A +-------+ ~ | |
1425 La atomicidad multicopia es una noción profundamente intuitiva sobre el
1428 todos las CPU o, alternativamente, que todas las CPU acuerdan el orden en
1429 que todos los stores se vuelven visibles. Sin embargo, el soporte para
1447 Y, y la carga de la CPU 3 desde Y devuelve 1. Esto indica que el store de
1448 la CPU 1 a X precede a la carga de la CPU 2 desde X y el store de esa CPU 2
1459 el valor que leyó), entonces en sistemas atómicos multicopia, la carga de
1460 la CPU B debe devolver el mismo valor que hizo la carga de la CPU A o algún
1461 valor posterior. Sin embargo, el kernel Linux no requiere que los sistemas
1464 El uso de una barrera de memoria general en el ejemplo anterior compensa
1465 cualquier falta de atomicidad multicopia. En el ejemplo, si la carga de la
1488 carga y store, no garantiza ordenar el store de la CPU 1. De forma que, si
1492 requieren barreras generales para garantizar que todas las CPU acurden el
1497 que -todas- las CPU percibirán el mismo orden de -todas- las operaciones.
1498 Por el contrario, una cadena de parejas de liberación-adquisición no
1500 que las CPU de la cadena estén de acuerdo en el orden combinado de los
1535 smp_store_release()/smp_load_acquire(), el siguiente resultado estaría
1541 cpu1() debe ver las escrituras de cpu0(), de modo que el siguiente
1546 Sin embargo, el orden proporcionado por una cadena de
1549 el siguiente resultado:
1553 Por otro lado, también el siguiente resultado es posible:
1559 pueden estar en desacuerdo con el orden. Este desacuerdo se debe al hecho
1563 Esto significa que cpu3() puede ver el store de cpu0() suceder -después- de
1565 acuerdo en que estas dos operaciones ocurrieron en el orden previsto.
1597 que evita que el el compilador mueva los accesos a la memoria de cualquier
1609 (*) Evita que el compilador reordene los accesos tras barrier() para
1612 interrupt-handler (encargo de gestionar interrupciones) y el código
1627 el siguiente código:
1633 a[0]. Evite que tanto el compilador como la CPU hagan esto de la
1643 variable. Tal fusión puede hacer que el compilador "optimice" el
1649 en el siguiente código, que, aunque en cierto sentido es legítimo
1651 que el desarrollador pretendía:
1657 Use READ_ONCE() para evitar que el compilador le haga esto:
1663 en los casos en que la alta presión de los registros impida que el
1671 Esto podría resultar en el siguiente código, que es perfectamente
1679 pasar un cero a hacer_algo_con() en el caso de que la variable a sea
1683 De nuevo, use READ_ONCE() para evitar que el compilador haga esto:
1688 Tenga en cuenta que si el compilador se queda sin registros, podría
1696 sabe cual será su valor. Por ejemplo, si el compilador puede probar
1697 que el valor de la variable 'a' siempre es cero, puede optimizar este
1709 que el compilador llevará a cabo su prueba asumiendo que la CPU actual
1717 Pero, por favor, tenga en cuenta que el compilador también está
1718 observando de cerca lo que usted hace con el valor después de
1720 una macro de preprocesador con el valor 1:
1725 Entonces el compilador sabe que el resultado del operador "%" aplicado
1726 a MAX siempre será cero, nuevamente permitiendo que el compilador
1727 optimice el código hasta su casi inexistencia. (Aún se cargará desde
1730 (*) De manera similar, el compilador tiene derecho a omitir un store por
1731 completo si sabe que la variable ya tiene el valor almacenado.
1732 Nuevamente, el compilador asume que la CPU actual es la única que
1733 almacena la variable, lo que puede hacer que el compilador haga
1741 El compilador observa que el valor de la variable 'a' ya es cero, por
1742 lo que bien podría omitir el segundo store. Esto supondría una fatal
1746 Use WRITE_ONCE() para evitar que el compilador haga este tipo de
1755 entre el código de nivel de proceso y un controlador de interrupción:
1769 No hay nada que impida que el compilador transforme
1806 Debe suponer que el compilador puede mover READ_ONCE() y WRITE_ONCE()
1811 y WRITE_ONCE() son más selectivos: Con READ_ONCE() y WRITE_ONCE(), el
1812 compilador solo necesita olvidar el contenido de ubicaciones de
1813 memoria indicadas, mientras que con barrier() el compilador debe
1814 descartar el valor de todas las ubicaciones de memoria que tiene
1816 Por supuesto, el compilador también debe respetar el orden en que
1821 como en el siguiente ejemplo:
1835 En el código de un solo subproceso, esto no solo es seguro, sino que
1853 acceder con una sola instrucción de referencia de memoria, evite el
1855 tearing), en el que un solo gran acceso es reemplazado por múltiples
1858 bits, el compilador podría tener la tentación de usar dos
1860 el siguiente store de 32 bits:
1866 instrucciones el construir la constante y luego almacenarla. Por lo
1870 volátil. En ausencia de tales errores, el uso de WRITE_ONCE() evita el
1871 desgarro del store en el siguiente ejemplo:
1886 hay markings volátiles, el compilador estaría en su derecho de
1890 en 'foo2.b'. READ_ONCE() y WRITE_ONCE() nuevamente evitan el desgarro
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]`
1927 tendría que cargar el valor de b antes de cargar a[b]), sin embargo, no hay
1928 garantía alguna en la especificación de C sobre que el compilador no puede
1929 especular el valor de b (por ejemplo, es igual a 1) y carga a[b] antes que
1930 b (ej. tmp = a[1]; if (b != 1) tmp = a[b]; ). También existe el problema de
1933 acerca de estos problemas, sin embargo, el macro READ_ONCE() es un buen
1943 controlar el orden de referencias a memoria compartida en sistemas SMP,
1944 aunque el uso de bloqueo en su lugar sea suficiente.
1959 Asigna el valor a la variable y luego inserta una barrera de memoria
1968 barreras de memoria, pero donde el código necesita una barrera de
1979 muerto y luego disminuye el contador de referencias del objeto:
1985 Esto asegura que la marca de muerte en el objeto se perciba como
1986 fijada *antes* de que disminuya el contador de referencia.
1996 Estos son usados con memoria consistente para garantizar el orden de
2002 para indicar si el descriptor pertenece al dispositivo o a la CPU, y
2007 /* no leer los datos hasta que tengamos el descriptor */
2024 El dma_rmb() nos permite garantizar que el dispositivo ha liberado su
2025 propiedad antes de que leamos los datos del descriptor, y el dma_wmb()
2026 permite garantizar que los datos se escriben en el descriptor antes de
2027 que el dispositivo pueda ver que ahora tiene la propiedad. El dma_mb()
2035 obtener más información sobre accesorios de E/S relajados y el archivo
2042 para los que las modificaciones se escriben en el almacenamiento
2046 usamos pmem_wmb() para garantizar que los stores hayan alcanzado el
2048 han actualizado el almacenamiento persistente antes de cualquier
2053 lectura existentes son suficientes para garantizar el orden de
2063 espera tenga implicaciones en el rendimiento.
2069 Algunas de las otras funciones en el kernel Linux implican barreras de
2122 sea debido a no poder obtener el bloqueo de inmediato, o debido a que
2123 recibieron una señal de desbloqueo mientras dormían esperando que el
2147 respectivamente, este mismo orden puede ocurrir si el cerrojo ACQUIRE y
2153 De manera similar, el caso inverso de un RELEASE seguido de un ACQUIRE no
2169 con suceder, el RELEASE simplemente se completaría, evitando así el
2174 Un punto clave es que solo estamos hablando de la CPU re-haciendo el
2175 orden, no el compilador. Si el compilador (o, ya puestos, el
2178 Pero supongamos que la CPU reordenó las operaciones. En este caso, el
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
2188 Pero, ¿y si el cerrojo es un cerrojo que duerme ("sleeplock")? En tal
2189 caso, el código intentará entrar al scheduler, donde eventualmente
2191 anterior para completar, nuevamente desentrañando el punto muerto. Podría
2244 que se pueden ver como una interacción entre dos piezas de datos: el estado
2245 de la task (hilo, proceso, tarea) que espera el evento y los datos globales
2246 utilizados para indicar el evento. Para asegurarse de que estos parezcan
2247 suceder en el orden correcto, las primitivas para comenzar el proceso de ir
2251 En primer lugar, el agente durmiente normalmente sigue algo similar a esta
2262 set_current_state() después de haber alterado el estado de la tarea:
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
2292 En segundo lugar, el código que realiza una activación normalmente se
2306 de la tarea. En particular, se encuentra entre el STORE para indicar el
2307 evento y el STORE para configurar TASK_RUNNING (hilo ejecutando):
2318 donde "task" es el subproceso que se está despertando y es igual al
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
2363 durmiente y el despierto _no_ ordenan varios stores antes del despertar con
2364 respecto a cargas de los valores guardados después de que el durmiente haya
2365 llamado a set_current_state(). Por ejemplo, si el durmiente hace:
2373 y el que despierta hace:
2379 no existe garantía de que el cambio a event_indicated sea percibido por
2380 el durmiente de manera que venga después del cambio a my_data. En tal
2381 circunstancia, el código en ambos lados debe sacar sus propias barreras de
2382 memoria entre los separados accesos a datos. Por lo tanto, el durmiente
2391 y el que despierta debería hacer:
2411 sustancial de barrera: una que afecta el orden de acceso a la memoria en
2419 Considere lo siguiente: el sistema tiene un par de spinlocks (M) y (Q), y
2448 Bajo operación normal, el re-ordenamiento de una operación de memoria
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
2471 bastante caros, por lo que puede ser preferible operar sin el uso de un
2494 (1) leer el siguiente puntero del registro de este proceso que espera,
2495 para saber dónde está el registro del siguiente waiter;
2497 (2) leer el puntero a la estructura de tareas del waiter;
2499 (3) borrar el puntero de la tarea para decirle al waiter que se le ha dado
2500 el semáforo;
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
2519 a que se borre su puntero de tarea antes de continuar. Dado que el registro
2520 está en la pila del proceso que espera, esto significa que si el puntero de
2521 la tarea se borra _antes_ de que se lea el siguiente puntero de la lista,
2522 otra CPU podría comenzar a procesar el proceso que espera y podría romper
2523 el stack del proceso que espera antes de que la función up*() tenga la
2524 oportunidad de leer el puntero que sigue.
2539 Reanudar el procesamiento
2547 Esto podría solucionarse usando el bloqueo de semáforo, pero luego la
2548 función down_xxx() tiene que obtener innecesariamente el spinlock
2549 nuevamente, después de ser despertado el hilo.
2563 que todos los accesos a memoria antes de la barrera se completarán en el
2567 solo una barrera del compilador, asegurándose así de que el compilador
2568 emita las instrucciones en el orden correcto sin realmente intervenir en la
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
2597 actual haya sido resuelta, por lo tanto, el controlador de interrupción no
2602 el core de ese controlador habla con la tarjeta estando en desactivación de
2603 interrupción y luego se invoca el controlador de interrupción del
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
2636 interrupciones para garantizar el orden.
2646 específicos de sus sistemas de destino, con el fin de lograr la
2648 portátiles entre múltiples arquitecturas e implementaciones de bus, el
2660 entre estos. Esto asegura que los registros de acceso MMIO por el
2662 el orden del programa.
2673 emitidas por, o bien propagadas por, el mismo subproceso. Esto asegura
2679 4. Un readX() de un subproceso del CPU, desde el periférico, se
2681 el mismo subproceso pueda comenzar. Esto asegura que las lecturas de
2683 dma_alloc_coherent(), no verán datos obsoletos después de leer el
2687 5. Un readX() por un subproceso del CPU, desde el periférico, se
2689 comenzar a ejecutarse en el mismo subproceso. Esto asegura que dos
2712 se ordenarán con respecto a otros accesos desde el mismo hilo de la CPU,
2713 al mismo periférico, cuando se opera en punteros __iomem asignados con el
2747 Como arriba, los puntos de entrada insX() y outsX() proporcionan el mismo
2753 Estos funcionarán adecuadamente para el tipo de acceso que realmente están
2757 writesX()), todo lo anterior supone que el periférico subyacente es
2769 powerpc o frv), por lo que el caso más relajado (es decir, DEC Alpha) se
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,
2779 [*] Algunas instrucciones tienen más de un efecto, como cambiar el
2785 adyacentes cargan un valor inmediato en el mismo registro, la primera puede
2789 De manera similar, se debe suponer que el compilador podría reordenar la
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.
2804 través del caché, el sistema de memoria tiene que incluir los cachés de la
2807 la línea de puntos en el siguiente diagrama):
2833 caché de la CPU, seguirá pareciendo como si el acceso total a la memoria
2838 El núcleo de la CPU puede ejecutar instrucciones en el orden que considere
2846 De lo que se ocupan las barreras de la memoria es de controlar el orden en
2847 que los accesos cruzan, desde el lado de la CPU, hasta el lado de memoria,
2848 y el orden en que los otros observadores perciben los efectos en el sistema
2853 hubieran sucedido en el orden del programa.
2855 [!] Los accesos a MMIO u otros dispositivos pueden pasar por alto el
2857 a través de la cual se accede a los dispositivos y/o el uso de
2875 desde el caché de una CPU, después de que el dispositivo haya puesto sus
2876 propios datos, o las líneas de caché presentes en el caché de la CPU pueden
2877 simplemente ocultar el hecho de que la memoria RAM se haya actualizado,
2878 hasta el momento en que la caché se descarta de la memoria caché de la CPU
2894 Entre dichas propiedades, suele existir el hecho de que tales accesos
2895 eluden el almacenamiento en caché por completo e ir directamente a los
2899 que el caché debe ser vaciado entre la escritura de la memoria caché, y el
2908 de memoria exactamente en el orden especificado, de modo que si a la CPU se
2909 entrega, por ejemplo, el siguiente fragmento de código a ejecutar:
2919 secuencia de operaciones vistas por observadores externos en el sistema:
2930 (*) las cargas se pueden hacer especulativamente, y el resultado es
2934 se haya obtenido el resultado en el momento equivocado de la secuencia
2937 (*) el orden de los accesos a memoria se puede reorganizar para promover
2940 (*) las cargas y los stores se pueden combinar para mejorar el rendimiento
2947 mecanismos de coherencia pueden aliviar esto, una vez que el store
2951 Entonces, digamos que lo que otra CPU podría observar en el fragmento de
2961 barrera de memoria. Por ejemplo con el siguiente código:
2971 suponer que el resultado final se parecerá a:
2973 U == el valor original de *A
2986 que READ_ONCE() y WRITE_ONCE() -no- son opcionales en el ejemplo anterior,
3007 que el efecto del almacenamiento de V a *A se pierde. Similarmente:
3029 cachés con el sistema de coherencia de memoria, lo que hace que parezca un
3030 cambio en el puntero, frente a que los nuevos datos se produzcan en el
3033 Alpha define el modelo de memoria del kernel Linux, aunque a partir de
3035 redujo en gran medida su impacto en el modelo de memoria.
3042 afectados por los efectos de SMP incluso si el "host" (huésped) en sí se
3048 bajo nivel virt_mb() etc. Estas tienen el mismo efecto que smp_mb(), etc.
3068 con el consumidor. Vea: