2 This is a version of Documentation/memory-barriers.txt translated into
3 Spanish by Carlos Bilbao <carlos.bilbao@amd.com>. If you find any
4 difference between this document and the original file or a problem with
5 the translation, please contact the maintainer of this file. Please also
6 note that the purpose of this file is to be easier to read for non English
7 (read: Spanish) speakers and is not intended as a fork. So if you have any
8 comments or updates for this file please update the original English file
9 first. The English version is definitive, and readers should look there if
12 ======================================
13 BARRERAS DE MEMORIA EN EL KERNEL LINUX
14 ======================================
16 Documento original: David Howells <dhowells@redhat.com>
17 Paul E. McKenney <paulmck@linux.ibm.com>
18 Will Deacon <will.deacon@arm.com>
19 Peter Zijlstra <peterz@infradead.org>
21 Traducido por: Carlos Bilbao <carlos.bilbao@amd.com>
22 Nota: Si tiene alguna duda sobre la exactitud del contenido de esta
23 traducción, la única referencia válida es la documentación oficial en
30 Este documento no es una especificación; es intencionalmente (por motivos
31 de brevedad) y sin querer (por ser humanos) incompleta. Este documento
32 pretende ser una guía para usar las diversas barreras de memoria
33 proporcionadas por Linux, pero ante cualquier duda (y hay muchas) por favor
34 pregunte. Algunas dudas pueden ser resueltas refiriéndose al modelo de
35 consistencia de memoria formal y documentación en tools/memory-model/. Sin
36 embargo, incluso este modelo debe ser visto como la opinión colectiva de
37 sus maintainers en lugar de que como un oráculo infalible.
39 De nuevo, este documento no es una especificación de lo que Linux espera
42 El propósito de este documento es doble:
44 (1) especificar la funcionalidad mínima en la que se puede confiar para
45 cualquier barrera en concreto, y
47 (2) proporcionar una guía sobre cómo utilizar las barreras disponibles.
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
51 arquitectura proporciona menos de eso, dicha arquitectura es incorrecta.
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.
61 (*) Modelo abstracto de acceso a memoria.
63 - Operaciones del dispositivo.
66 (*) ¿Qué son las barreras de memoria?
68 - Variedades de barrera de memoria.
69 - ¿Qué no se puede asumir sobre las barreras de memoria?
70 - Barreras de dirección-dependencia (históricas).
71 - Dependencias de control.
72 - Emparejamiento de barreras smp.
73 - Ejemplos de secuencias de barrera de memoria.
74 - Barreras de memoria de lectura frente a especulación de carga.
75 - Atomicidad multicopia.
77 (*) Barreras explícitas del kernel.
79 - Barrera del compilador.
80 - Barreras de memoria de la CPU.
82 (*) Barreras de memoria implícitas del kernel.
84 - Funciones de adquisición de cerrojo.
85 - Funciones de desactivación de interrupciones.
86 - Funciones de dormir y despertar.
89 (*) Efectos de barrera adquiriendo intra-CPU.
91 - Adquisición vs accesos a memoria.
93 (*) ¿Dónde se necesitan barreras de memoria?
95 - Interacción entre procesadores.
96 - Operaciones atómicas.
97 - Acceso a dispositivos.
100 (*) Efectos de barrera de E/S del kernel.
102 (*) Modelo de orden mínimo de ejecución asumido.
104 (*) Efectos de la memoria caché de la CPU.
106 - Coherencia de caché.
107 - Coherencia de caché frente a DMA.
108 - Coherencia de caché frente a MMIO.
110 (*) Cosas que hacen las CPU.
112 - Y luego está el Alfa.
113 - Guests de máquinas virtuales.
115 (*) Ejemplos de usos.
117 - Buffers circulares.
122 ====================================
123 MODELO ABSTRACTO DE ACCESO A MEMORIA
124 ====================================
126 Considere el siguiente modelo abstracto del sistema:
131 +-------+ : +--------+ : +-------+
134 | CPU 1 |<----->| Memoria|<----->| CPU 2 |
137 +-------+ : +--------+ : +-------+
145 +---------->| tivo |<----------+
151 Cada CPU ejecuta un programa que genera operaciones de acceso a la memoria.
152 En la CPU abstracta, el orden de las operaciones de memoria es muy
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
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
157 funcionamiento aparente del programa.
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
162 sistema (las líneas discontinuas a puntos).
164 Por ejemplo, considere la siguiente secuencia de eventos:
167 =============== ===============
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
176 STORE A=3, STORE B=4, y=LOAD A->3, x=LOAD B->4
177 STORE A=3, STORE B=4, x=LOAD B->4, y=LOAD A->3
178 STORE A=3, y=LOAD A->3, STORE B=4, x=LOAD B->4
179 STORE A=3, y=LOAD A->3, x=LOAD B->2, STORE B=4
180 STORE A=3, x=LOAD B->2, STORE B=4, y=LOAD A->3
181 STORE A=3, x=LOAD B->2, y=LOAD A->3, STORE B=4
182 STORE B=4, STORE A=3, y=LOAD A->3, x=LOAD B->4
186 y por lo tanto puede resultar en cuatro combinaciones diferentes de
194 Además, los stores asignados por una CPU al sistema de memoria pueden no
195 ser percibidos por los loads realizados por otra CPU en el mismo orden en
196 que fueron realizados.
198 Como otro ejemplo, considere esta secuencia de eventos:
201 =============== ===============
202 { A == 1, B == 2, C == 3, P == &A, Q == &C }
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
208 secuencia, cualquiera de los siguientes resultados son posibles:
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.
217 OPERACIONES DEL DISPOSITIVO
218 ---------------------------
220 Algunos dispositivos presentan sus interfaces de control como colecciones
221 de ubicaciones de memoria, pero el orden en que se accede a los registros
222 de control es muy importante. Por ejemplo, imagine una tarjeta ethernet con
223 un conjunto de registros a los que se accede a través de un registro de
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:
230 pero esto podría aparecer como cualquiera de las siguientes dos secuencias:
232 STORE *A = 5, x = LOAD *D
233 x = LOAD *D, STORE *A = 5
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.
242 Hay algunas garantías mínimas que se pueden esperar de una CPU:
244 (*) En cualquier CPU dada, los accesos a la memoria dependiente se
245 emitirán en orden, con respeto a sí mismo. Esto significa que para:
247 Q = READ_ONCE(P); D = READ_ONCE(*Q);
249 donde READ_ONCE() es LEER_UNA_VEZ(), la CPU emitirá las siguientes
250 operaciones de memoria:
252 Q = LOAD P, D = LOAD *Q
254 y siempre en ese orden. Sin embargo, en DEC Alpha, READ_ONCE() también
255 emite una instrucción de barrera de memoria, de modo que una CPU DEC
256 Alpha, sin embargo emite las siguientes operaciones de memoria:
258 Q = LOAD P, MEMORY_BARRIER, D = LOAD *Q, MEMORY_BARRIER
260 Ya sea en DEC Alpha o no, READ_ONCE() también evita que el compilador
261 haga cosas inapropiadas.
263 (*) Los loads y stores superpuestos dentro de una CPU en particular
264 parecerán ser ordenados dentro de esa CPU. Esto significa que para:
266 a = READ_ONCE(*X); WRITE_ONCE(*X, b);
268 donde WRITE_ONCE() es ESCRIBIR_UNA_VEZ(), la CPU solo emitirá la
269 siguiente secuencia de operaciones de memoria:
271 a = LOAD *X, STORE *X = b
275 WRITE_ONCE(*X, c); d = READ_ONCE(*X);
279 STORE *X = c, d = LOAD *X
281 (Los loads y stores se superponen si están destinados a piezas
282 superpuestas de memoria).
284 Y hay una serie de cosas que _deben_ o _no_ deben asumirse:
286 (*) _No_debe_ asumirse que el compilador hará lo que usted quiera
287 con referencias de memoria que no están protegidas por READ_ONCE() y
288 WRITE ONCE(). Sin ellos, el compilador tiene derecho a hacer todo tipo
289 de transformaciones "creativas", que se tratan en la sección BARRERA
292 (*) _No_debe_ suponerse que se emitirán loads y stores independientes
293 en el orden dado. Esto significa que para:
295 X = *A; Y = *B; *D = Z;
297 podemos obtener cualquiera de las siguientes secuencias:
299 X = LOAD *A, Y = LOAD *B, STORE *D = Z
300 X = LOAD *A, STORE *D = Z, Y = LOAD *B
301 Y = LOAD *B, X = LOAD *A, STORE *D = Z
302 Y = LOAD *B, STORE *D = Z, X = LOAD *A
303 STORE *D = Z, X = LOAD *A, Y = LOAD *B
304 STORE *D = Z, Y = LOAD *B, X = LOAD *A
306 (*) Se _debe_ suponer que los accesos de memoria superpuestos pueden
307 fusionarse o ser descartados. Esto significa que para:
309 X = *A; Y = *(A + 4);
311 podemos obtener cualquiera de las siguientes secuencias:
313 X = LOAD *A; Y = LOAD *(A + 4);
314 Y = LOAD *(A + 4); X = LOAD *A;
315 {X, Y} = LOAD {*A, *(A + 4) };
319 *A = X; *(A + 4) = Y;
321 podemos obtener cualquiera de:
323 STORE *A = X; STORE *(A + 4) = Y;
324 STORE *(A + 4) = Y; STORE *A = X;
325 STORE {*A, *(A + 4) } = {X, Y};
327 Y hay anti-garantías:
329 (*) Estas garantías no se aplican a los campos de bits, porque los
330 compiladores a menudo generan código para modificarlos usando
331 secuencias de lectura-modificación-escritura no atómica. No intente
332 utilizar campos de bits para sincronizar algoritmos paralelos.
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
337 campo de bits dado están protegidos por diferentes locks, las
338 secuencias de lectura-modificación-escritura no atómicas del lock
339 pueden causar una actualización a una campo para corromper el valor de
342 (*) Estas garantías se aplican solo a escalares correctamente alineados y
343 dimensionados. De "tamaño adecuado" significa actualmente variables que
344 son del mismo tamaño que "char", "short", "int" y "long".
345 "Adecuadamente alineado" significa la alineación natural, por lo tanto,
346 no hay restricciones para "char", alineación de dos bytes para "short",
347 alineación de cuatro bytes para "int", y alineación de cuatro u ocho
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í
350 que tenga cuidado cuando utilice compiladores anteriores a C11 (por
351 ejemplo, gcc 4.6). La parte de la norma que contiene esta garantía es
352 la Sección 3.14, que define "ubicación de memoria" de la siguiente
356 ya sea un objeto de tipo escalar, o una secuencia máxima
357 de campos de bits adyacentes, todos con ancho distinto de cero
359 NOTE 1: Dos hilos de ejecución pueden actualizar y acceder
360 ubicaciones de memoria separadas sin interferir entre
363 NOTE 2: Un campo de bits y un miembro adyacente que no es un campo de
364 bits están en ubicaciones de memoria separadas. Lo mismo sucede con
365 dos campos de bits, si uno se declara dentro de un declaración de
366 estructura anidada y el otro no, o si las dos están separados por una
367 declaración de campo de bits de longitud cero, o si están separados por
368 un miembro no declarado como campo de bits. No es seguro actualizar
369 simultáneamente dos campos de bits en la misma estructura si entre
370 todos los miembros declarados también hay campos de bits, sin importar
371 cuál resulta ser el tamaño de estos campos de bits intermedios.
374 ==================================
375 ¿QUÉ SON LAS BARRERAS DE MEMORIA?
376 ==================================
378 Como se puede leer arriba, las operaciones independientes de memoria se
379 realizan de manera efectiva en orden aleatorio, pero esto puede ser un
380 problema para la interacción CPU-CPU y para la E/S ("I/O"). Lo que se
381 requiere es alguna forma de intervenir para instruir al compilador y al
382 CPU para restringir el orden.
384 Las barreras de memoria son este tipo de intervenciones. Imponen una
385 percepción de orden parcial, sobre las operaciones de memoria a ambos lados
388 Tal cumplimiento es importante porque las CPUs y otros dispositivos en un
389 sistema pueden usar una variedad de trucos para mejorar el rendimiento,
390 incluido el reordenamiento, diferimiento y combinación de operaciones de
391 memoria; cargas especulativas; predicción de "branches" especulativos y
392 varios tipos de almacenamiento en caché. Las barreras de memoria se
393 utilizan para anular o suprimir estos trucos, permitiendo que el código
394 controle sensatamente la interacción de múltiples CPU y/o dispositivos.
397 VARIEDADES DE BARRERA DE MEMORIA
398 ---------------------------------
400 Las barreras de memoria vienen en cuatro variedades básicas:
402 (1) Barreras de memoria al escribir o almacenar (Write or store memory
405 Una barrera de memoria de escritura garantiza que todas las
406 operaciones de STORE especificadas antes de que la barrera aparezca
407 suceden antes de todas las operaciones STORE especificadas después
408 de la barrera, con respecto a los otros componentes del sistema.
410 Una barrera de escritura es un orden parcial solo en los stores; No
411 es requerido que tenga ningún efecto sobre los loads.
413 Se puede considerar que una CPU envía una secuencia de operaciones de
414 store al sistema de memoria a medida que pasa el tiempo. Todos los
415 stores _antes_ de una barrera de escritura ocurrirán _antes_ de todos
416 los stores después de la barrera de escritura.
418 [!] Tenga en cuenta que las barreras de escritura normalmente deben
419 combinarse con read o barreras de address-dependency barriers
420 (dependencia de dirección); consulte la subsección
421 "Emparejamiento de barreras smp".
424 (2) Barrera de dependencia de dirección (histórico).
426 Una barrera de dependencia de dirección es una forma más débil de
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
430 load), una barrera de dependencia de dirección sería necesaria para
431 asegurarse de que el objetivo de la segunda carga esté actualizado
432 después de acceder a la dirección obtenida por la primera carga.
434 Una barrera de dependencia de direcciones es una ordenación parcial en
435 laods de direcciones interdependientes; no se requiere que tenga
436 ningún efecto en los stores, ya sean cargas de memoria o cargas
437 de memoria superpuestas.
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
441 puede percibir. Una barrera de dependencia de dirección emitida por
442 la CPU en cuestión garantiza que para cualquier carga que la preceda,
443 si esa carga toca alguna secuencia de stores de otra CPU, entonces
444 en el momento en que la barrera se complete, los efectos de todos los
445 stores antes del cambio del load serán perceptibles por cualquier
446 carga emitida después la barrera de la dependencia de la dirección.
448 Consulte la subsección "Ejemplos de secuencias de barrera de memoria"
449 para ver los diagramas mostrando las restricciones de orden.
451 [!] Tenga en cuenta que la primera carga realmente tiene que tener una
452 dependencia de _dirección_ y no es una dependencia de control. Si la
453 dirección para la segunda carga depende de la primera carga, pero la
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_
456 y se requiere una barrera de lectura completa o superior. Consulte la
457 subsección "Dependencias de control" para más información.
459 [!] Tenga en cuenta que las barreras de dependencia de dirección
460 normalmente deben combinarse con barreras de escritura; consulte la
461 subsección "Emparejamiento de barreras smp".
463 [!] Desde el kernel v5.9, se eliminó la API del kernel para barreras
464 de memoria de direcciones explícitas. Hoy en día, las APIs para marcar
465 cargas de variables compartidas, como READ_ONCE() y rcu_dereference(),
466 proporcionan barreras de dependencia de dirección implícitas.
468 (3) Barreras de memoria al leer o cargar (Read or load memory
471 Una barrera de lectura es una barrera de dependencia de direcciones,
472 más una garantía de que todas las operaciones de LOAD especificadas
473 antes de la barrera parecerán ocurrir antes de todas las operaciones
474 de LOAD especificadas después de la barrera con respecto a los demás
475 componentes del sistema.
477 Una barrera de lectura es un orden parcial solo en cargas; no es
478 necesario que tenga ningún efecto en los stores.
480 Las barreras de memoria de lectura implican barreras de dependencia de
481 direcciones, y por tanto puede sustituirlas por estas.
483 [!] Tenga en mente que las barreras de lectura normalmente deben
484 combinarse con barreras de escritura; consulte la subsección
485 "Emparejamiento de barreras smp".
487 (4) Barreras de memoria generales
489 Una barrera de memoria general proporciona la garantía de que todas
490 las operaciones LOAD y STORE especificadas antes de que la barrera
491 aparezca suceden antes de que todas las operaciones LOAD y STORE
492 especificadas después de la barrera con respecto a los demás
493 componentes del sistema.
495 Una barrera de memoria general es un orden parcial tanto en
496 operaciones de carga como de almacenamiento.
498 Las barreras de memoria generales implican barreras de memoria tanto
499 de lectura como de escritura, de modo que pueden sustituir a
502 Y un par de variedades implícitas:
504 (5) ACQUIRE (de adquisición).
506 Esto actúa como una barrera permeable unidireccional. Garantiza que
507 toda las operaciones de memoria después de la operación ACQUIRE
508 parezcan suceder después de la ACQUIRE con respecto a los demás
509 componentes del sistema. Las operaciones ACQUIRE incluyen operaciones
510 LOCK y smp_load_acquire(), y operaciones smp_cond_load_acquire().
512 Las operaciones de memoria que ocurren antes de una operación ACQUIRE
513 pueden parecer suceder después de que se complete.
515 Una operación ACQUIRE casi siempre debe estar emparejada con una
516 operación RELEASE (de liberación).
519 (6) Operaciones RELEASE (de liberación).
521 Esto también actúa como una barrera permeable unidireccional.
522 Garantiza que todas las operaciones de memoria antes de la operación
523 RELEASE parecerán ocurrir antes de la operación RELEASE con respecto a
524 los demás componentes del sistema. Las operaciones de RELEASE incluyen
525 operaciones de UNLOCK y operaciones smp_store_release().
527 Las operaciones de memoria que ocurren después de una operación
528 RELEASE pueden parecer suceder antes de que se complete.
530 El uso de las operaciones ACQUIRE y RELEASE generalmente excluye la
531 necesidad de otros tipos de barrera de memoria. Además, un par
532 RELEASE+ACQUIRE NO garantiza actuar como una barrera de memoria
533 completa. Sin embargo, después de un ACQUIRE de una variable dada,
534 todos los accesos a la memoria que preceden a cualquier anterior
535 RELEASE en esa misma variable están garantizados como visibles. En
536 otras palabras, dentro de la sección crítica de una variable dada,
537 todos los accesos de todas las secciones críticas anteriores para esa
538 variable habrán terminado de forma garantizada.
540 Esto significa que ACQUIRE actúa como una operación mínima de
541 "adquisición" y RELEASE actúa como una operación mínima de
544 Un subconjunto de las operaciones atómicas descritas en atomic_t.txt
545 contiene variantes de ACQUIRE y RELEASE, además de definiciones
546 completamente ordenadas o relajadas (sin barrera semántica). Para
547 composiciones atómicas que realizan tanto un load como store, la semántica
548 ACQUIRE se aplica solo a la carga y la semántica RELEASE se aplica sólo a
549 la parte de la operación del store.
551 Las barreras de memoria solo son necesarias cuando existe la posibilidad de
552 interacción entre dos CPU o entre una CPU y un dispositivo. Si se puede
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
558 arquitecturas pueden proporcionar garantías más sustanciales, pero no se
559 puede confiar en estas fuera de esa arquitectura en específico.
562 ¿QUÉ NO SE PUEDE ASUMIR SOBRE LAS BARRERAS DE LA MEMORIA?
563 ---------------------------------------------------------
565 Hay ciertas cosas que las barreras de memoria del kernel Linux no
568 (*) No hay garantía de que ninguno de los accesos a la memoria
569 especificados antes de una barrera de memoria estará _completo_ al
570 completarse una instrucción de barrera de memoria; se puede considerar
571 que la barrera dibuja una línea en la cola de acceso del CPU que no
572 pueden cruzar los accesos del tipo correspondiente.
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
577 ve los efectos de los primeros accesos que ocurren de la CPU, pero lea
578 el siguiente argumento:
580 (*) No hay garantía de que una CPU vea el orden correcto de los efectos
581 de los accesos de una segunda CPU, incluso _si_ la segunda CPU usa una
582 barrera de memoria, a menos que la primera CPU _también_ use una
583 barrera de memoria coincidente (vea el subapartado "Emparejamiento de
586 (*) No hay garantía de que alguna pieza intermedia fuera del hardware[*]
587 del CPU no reordenará los accesos a la memoria. Los mecanismos de
588 coherencia de caché del CPU deben propagar los efectos indirectos de
589 una barrera de memoria entre las CPU, pero es posible que no lo hagan
592 [*] Para obtener información sobre bus mastering DMA y coherencia, lea:
594 Documentation/driver-api/pci/pci.rst
595 Documentation/core-api/dma-api-howto.rst
596 Documentation/core-api/dma-api.rst
599 BARRERA DE DEPENDENCIA DE DIRECCIÓN (HISTÓRICO)
600 -----------------------------------------------
602 A partir de la versión 4.15 del kernel Linux, se agregó un smp_mb() a
603 READ_ONCE() para DEC Alpha, lo que significa que las únicas personas que
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
606 READ_ONCE() por dentro. Para aquellos que lo necesitan, y para aquellos que
607 estén interesados desde un punto de vista histórico, aquí está la historia
608 de las barreras de dependencia de dirección.
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
612 dirección no son necesarias para situaciones de carga a store.
614 El requisito de las barreras de dependencia de dirección es un poco sutil,
615 y no siempre es obvio que sean necesarias. Para ilustrar, considere la
616 siguiente secuencia de eventos:
619 =============== ===============
620 { A == 1, B == 2, C == 3, P == &A, Q == &C }
622 <barrera de escritura>
624 Q = READ_ONCE_OLD(P);
627 [!] READ_ONCE_OLD() corresponde a READ_ONCE() del kernel anterior a 4.15,
628 que no implica una barrera de dependencia de direcciones.
630 Hay una clara dependencia de dirección aquí, y parecería que al final de
631 la secuencia, Q debe ser &A o &B, y que:
633 (Q == &A) implica (D == 1)
634 (Q == &B) implica (D == 4)
636 ¡Pero! La percepción de la CPU 2 de P puede actualizarse _antes_ de su
637 percepción de B, por lo tanto dando lugar a la siguiente situación:
639 (Q == &B) y (D == 2) ????
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
643 ciertas CPU reales (como DEC Alfa).
645 Para lidiar con esto, READ_ONCE() proporciona una barrera de dependencia
646 de dirección implícita desde el lanzamiento del kernel v4.15:
649 =============== ===============
650 { A == 1, B == 2, C == 3, P == &A, Q == &C }
652 <barrera de escritura>
655 <barrera de dependencia de dirección implícita>
658 Esto refuerza la ocurrencia de una de las dos implicaciones, y previene la
659 tercera posibilidad de surgir.
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
664 que, por ejemplo, un banco de caché procesa líneas de caché pares y el otro
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
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).
673 No se requiere una barrera de dependencia de dirección para ordenar
674 escrituras dependientes porque las CPU que admite el kernel Linux no
675 escriben hasta que están seguros (1) de que la escritura realmente
676 sucederá, (2) de la ubicación de la escritura, y (3) del valor a escribir.
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
679 y romper dependencias en muchas formas altamente creativas.
682 =============== ===============
683 { A == 1, B == 2, C = 3, P == &A, Q == &C }
685 <barrera de escritura>
687 Q = READ_ONCE_OLD(P);
690 Por lo tanto, no se requiere ninguna barrera de dependencia de direcciones
691 para ordenar la lectura en Q con el load en *Q. En otras palabras, este
692 resultado está prohibido, incluso sin una barrera de dependencia de
693 dirección implícita del READ_ONCE() moderno:
695 (Q == &B) && (B == 4)
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
699 datos, junto con los costosos errores de caché asociados con tales
700 escrituras. Este patrón se puede utilizar para registrar raras condiciones
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
706 es local para la CPU que lo contiene. Lea la sección sobre "Atomicidad
707 multicopia" para más información.
710 La barrera de dependencia de dirección es muy importante para el sistema
711 RCU, por ejemplo. Vea rcu_assign_pointer() y rcu_dereference() en
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
714 del reemplazo parezca estar inicializado de manera incompleta.
716 Consulte también la subsección sobre "Coherencia de caché" para obtener un
717 ejemplo más completo.
719 DEPENDENCIAS DE CONTROL
720 -----------------------
722 Las dependencias de control pueden ser un poco complicadas porque los
723 compiladores actuales no las entienden. El propósito de esta sección es
724 ayudarle a prevenir que la ignorancia del compilador rompa su código.
726 Una dependencia de control load-load (de carga a carga) requiere una
727 barrera de memoria de lectura completa, no simplemente una barrera
728 (implícita) de dependencia de direcciones para que funcione correctamente.
729 Considere el siguiente fragmento de código:
732 <barrera implícita de dependencia de direcciones>
734 /* BUG: No hay dependencia de dirección!!! */
738 Esto no tendrá el efecto deseado porque no hay una dependencia de dirección
739 real, sino más bien una dependencia de control que la CPU puede
740 cortocircuitar al intentar predecir el resultado por adelantado, para que
741 otras CPU vean la carga de b como si hubiera ocurrido antes que la carga de
742 a. En cuyo caso lo que realmente se requiere es:
750 Sin embargo, los stores no se especulan. Esto significa que ordenar -es-
751 provisto para dependencias de control de load-store, como en el siguiente
759 Las dependencias de control se emparejan normalmente con otros tipos de
760 barreras. Dicho esto, tenga en cuenta que ni READ_ONCE() ni WRITE_ONCE()
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
767 variable 'a' siempre es distinta de cero, estaría dentro de sus derechos
768 para optimizar el ejemplo original eliminando la declaración "if", como:
771 b = 1; /* BUG: Compilador y CPU pueden ambos reordernar!!! */
773 Así que no deje de lado READ_ONCE().
775 Es tentador tratar de hacer cumplir el orden en stores idénticos en ambos
776 caminos del "if" de la siguiente manera:
789 Desafortunadamente, los compiladores actuales transformarán esto de la
790 siguiente manera en casos de alto nivel de optimización:
794 WRITE_ONCE(b, 1); /* BUG: No hay orden en load de a!!! */
796 /* WRITE_ONCE(b, 1); -- movido arriba, BUG!!! */
799 /* WRITE_ONCE(b, 1); -- movido arriba, BUG!!! */
803 Ahora no hay condicional entre la carga de 'a' y el store de 'b', lo que
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
806 incluso después de que se hayan aplicado todas las optimizaciones del
807 compilador. Por lo tanto, si necesita ordenar en este ejemplo, necesita
808 explícitamente barreras de memoria, por ejemplo, smp_store_release():
813 smp_store_release(&b, 1);
816 smp_store_release(&b, 1);
820 Por el contrario, sin barreras de memoria explícita, el control de un if
821 con dos opciones está garantizado solo cuando los stores difieren, por
833 Aún se requiere el inicial READ_ONCE() para evitar que el compilador toque
836 Además, debe tener cuidado con lo que hace con la variable local 'q', de lo
837 contrario, el compilador podría adivinar el valor y volver a eliminar el
838 necesario condicional. Por ejemplo:
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
859 agregar una barrier(), pero esto no ayuda. El condicional se ha ido, y la
860 barrera no lo traerá de vuelta. Por lo tanto, si confia en este orden, debe
861 asegurarse de que MAX sea mayor que uno, tal vez de la siguiente manera:
864 BUILD_BUG_ON(MAX <= 1); /* Orden de carga de a con store de b */
873 Tenga en cuenta una vez más que los stores de 'b' difieren. Si fueran
874 idénticos, como se señaló anteriormente, el compilador podría sacar ese
875 store fuera de la declaración 'if'.
877 También debe tener cuidado de no confiar demasiado en el cortocircuito
878 de la evaluación booleana. Considere este ejemplo:
884 Debido a que la primera condición no puede fallar y la segunda condición es
885 siempre cierta, el compilador puede transformar este ejemplo de la
886 siguiente manera, rompiendo la dependencia del control:
891 Este ejemplo subraya la necesidad de asegurarse de que el compilador no
892 pueda adivinar su código. Más generalmente, aunque READ_ONCE() fuerza
893 al compilador para emitir código para una carga dada, no fuerza al
894 compilador para usar los resultados.
896 Además, las dependencias de control se aplican solo a la cláusula then y
897 la cláusula else de la sentencia if en cuestión. En particular, no se
898 aplica necesariamente al código que sigue a la declaración if:
906 WRITE_ONCE(c, 1); /* BUG: No hay orden para la lectura de 'a'. */
908 Es tentador argumentar que, de hecho, existe un orden porque el compilador
909 no puede reordenar accesos volátiles y tampoco puede reordenar escrituras
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
922 Una CPU débilmente ordenada no tendría dependencia de ningún tipo entre la
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
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
927 las funciones invocado por esas dos cláusulas), no al código que sigue a
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
933 multicopia" para más información.
938 (*) Las dependencias de control pueden ordenar cargas anteriores para
939 stores posteriores. Sin embargo, no garantizan ningún otro tipo de
940 orden: No cargas previas contra cargas posteriores, ni
941 almacenamientos previos y luego nada. Si necesita tales formas de
942 orden, use smp_rmb(), smp_wmb() o, en el caso de stores anteriores y
943 cargas posteriores, smp_mb().
945 (*) Si ambos caminos de la declaración "if" comienzan con stores
946 idénticos de la misma variable, entonces esos stores deben ser
947 ordenados, ya sea precediéndoles a ambos con smp_mb() o usando
948 smp_store_release() para realizar el store. Tenga en cuenta que -no-
949 es suficiente usar barrier() al comienzo de cada caso de la
950 declaración "if" porque, como se muestra en el ejemplo anterior, la
951 optimización de los compiladores puede destruir la dependencia de
952 control respetando al pie de la letra la ley de barrier().
954 (*) Las dependencias de control requieren al menos un condicional en
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
962 reordenar las dependencia hasta su inexistencia. El uso cuidadoso de
963 READ_ONCE() o atomic{,64}_read() puede ayudarle a preservar la
964 dependencia de control. Consulte la sección BARRERA DEL COMPILADOR
965 para obtener más información al respecto.
967 (*) Las dependencias de control se aplican solo a la cláusula then y la
968 cláusula else de la sentencia "if" que contiene la dependencia de
969 control, incluyendo cualquier función a la que llamen dichas dos
970 cláusulas. Las dependencias de control no se aplican al código que
971 sigue a la instrucción if que contiene la dependencia de control.
973 (*) Las dependencias de control se emparejan normalmente con otros tipos
976 (*) Las dependencias de control no proporcionan atomicidad multicopia. Si
977 usted necesita todas las CPU para ver un store dado al mismo tiempo,
980 (*) Los compiladores no entienden las dependencias de control. Por lo
981 tanto es su trabajo asegurarse de que no rompan su código.
984 EMPAREJAMIENTO DE BARRERAS SMP
985 ------------------------------
987 Cuando se trata de interacciones CPU-CPU, ciertos tipos de barrera de
988 memoria deben estar siempre emparejados. La falta del apropiado
989 emparejamiento es casi seguro un error.
991 Las barreras generales se emparejan entre sí, aunque también se emparejan
992 con la mayoría de otro tipo de barreras, aunque sin atomicidad multicopia.
993 Una barrera de adquisición se empareja con una barrera de liberación, pero
994 ambas también pueden emparejarse con otras barreras, incluidas, por
995 supuesto, las barreras generales. Una barrera de escritura se empareja con
996 una barrera de dependencia de dirección, una dependencia de control, una
997 barrera de adquisición, una barrera de liberación, una barrera de lectura
998 o una barrera general. Del mismo modo, una barrera de lectura se empareja
999 con una de dependencia de control o barrera de dependencia de dirección con
1000 una barrera de escritura, una barrera de adquisición, una barrera de
1001 liberación o una barrera general:
1004 =============== ===============
1006 <barrera de escritura>
1007 WRITE_ONCE(b, 2); x = READ_ONCE(b);
1008 <barrera de lectura>
1014 =============== ===============================
1016 <barrera de escritura>
1017 WRITE_ONCE(b, &a); x = READ_ONCE(b);
1018 <barrera de dependencia de dirección implícita>
1024 =============== ===============================
1027 WRITE_ONCE(x, 1); if (r2 = READ_ONCE(x)) {
1028 <barrera de control implícita>
1032 assert(r1 == 0 || r2 == 0);
1034 Básicamente, la barrera de lectura siempre tiene que estar ahí, aunque
1035 puede ser del tipo "más débil".
1037 [!] Tenga en cuenta que normalmente se esperaría que los stores antes de la
1038 barrera de escritura se hagan coincidir con los stores después de la
1039 barrera de lectura o la barrera de dependencia de dirección, y viceversa:
1042 =================== ===================
1043 WRITE_ONCE(a, 1); }---- --->{ v = READ_ONCE(c);
1044 WRITE_ONCE(b, 2); } \ / { w = READ_ONCE(d);
1045 <barrera de escritura> \ <barrera de lectura>
1046 WRITE_ONCE(c, 3); } / \ { x = READ_ONCE(a);
1047 WRITE_ONCE(d, 4); }---- --->{ y = READ_ONCE(b);
1050 EJEMPLOS DE SECUENCIAS DE BARRERA DE MEMORIA
1051 --------------------------------------------
1053 En primer lugar, las barreras de escritura actúan como orden parcial en las
1054 operaciones de store. Considere la siguiente secuencia de eventos:
1057 =======================
1061 <barrera de escritura>
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
1067 conjunto desordenado { STORE A, STORE B, STORE C} todo ocurriendo antes del
1068 conjunto desordenado { STORE D, STORE E}:
1073 | |------>| C=3 | } /\
1074 | | : +------+ }----- \ -----> Eventos perceptibles para
1075 | | : | A=1 | } \/ el resto del sistema
1077 | CPU 1 | : | B=2 | }
1079 | | wwwwwwwwwwwwwwww } <--- En este momento la barrera de
1080 | | +------+ } escritura requiere que todos los
1081 | | : | E=5 | } stores anteriores a la barrera
1082 | | : +------+ } sean confirmados antes de que otros
1083 | |------>| D=4 | } store puedan suceder
1087 | Secuencia por la cual los stores son confirmados al
1088 | sistema de memoria por parte del CPU 1
1091 En segundo lugar, las barreras de dependencia de dirección actúan como
1092 órdenes parciales sobre la dirección de cargas dependientes. Considere la
1093 siguiente secuencia de eventos:
1096 ======================= =======================
1097 { B = 7; X = 9; Y = 8; C = &Y }
1100 <barrera de escritura>
1102 STORE D = 4 LOAD C (consigue &B)
1105 Sin intervención, la CPU 2 puede percibir los eventos en la CPU 1 en orden
1106 aleatorio a efectos prácticos, a pesar de la barrera de escritura emitida
1110 | | +------+ +-------+ | Secuencia de
1111 | |------>| B=2 |----- --->| Y->8 | | actualizado de
1112 | | : +------+ \ +-------+ | percepción en CPU 2
1113 | CPU 1 | : | A=1 | \ --->| C->&Y | V
1114 | | +------+ | +-------+
1115 | | wwwwwwwwwwwwwwww | : :
1117 | | : | C=&B |--- | : : +-------+
1118 | | : +------+ \ | +-------+ | |
1119 | |------>| D=4 | ----------->| C->&B |------>| |
1120 | | +------+ | +-------+ | |
1121 +-------+ : : | : : | |
1125 Percepción de B ---> | | B->7 |------>| |
1126 aparentemente incorrecta! | +-------+ | |
1129 La carga de X frena ---> \ | X->9 |------>| |
1130 el mantenimiento de \ +-------+ | |
1131 la coherencia de B ----->| B->2 | +-------+
1136 En el ejemplo anterior, la CPU 2 percibe que B es 7, a pesar de la carga de
1137 *C (que sería B) viniendo después del LOAD de C.
1139 Sin embargo, si se colocara una barrera de dependencia de dirección entre
1140 la carga de C y la carga de *C (es decir: B) en la CPU 2:
1143 ======================= =======================
1144 { B = 7; X = 9; Y = 8; C = &Y }
1147 <barrera de escritura>
1149 STORE D = 4 LOAD C (consigue &B)
1150 <barrera de dependencia de dirección>
1153 entonces ocurrirá lo siguiente:
1156 | | +------+ +-------+
1157 | |------>| B=2 |----- --->| Y->8 |
1158 | | : +------+ \ +-------+
1159 | CPU 1 | : | A=1 | \ --->| C->&Y |
1160 | | +------+ | +-------+
1161 | | wwwwwwwwwwwwwwww | : :
1163 | | : | C=&B |--- | : : +-------+
1164 | | : +------+ \ | +-------+ | |
1165 | |------>| D=4 | ----------->| C->&B |------>| |
1166 | | +------+ | +-------+ | |
1167 +-------+ : : | : : | |
1171 | | X->9 |------>| |
1173 Se asegura de que ---> \ aaaaaaaaaaaaaaaaa | |
1174 los efectos anteriores al \ +-------+ | |
1175 store de C sean percibidos ----->| B->2 |------>| |
1176 por los siguientes loads +-------+ | |
1180 Y en tercer lugar, una barrera de lectura actúa como un orden parcial sobre
1181 las cargas. Considere la siguiente secuencia de eventos:
1184 ======================= =======================
1187 <barrera de escritura>
1192 Sin intervención, la CPU 2 puede elegir percibir los eventos en la CPU 1 en
1193 algún orden aleatorio a efectos prácticos, a pesar de la barrera de
1194 escritura emitida por la CPU 1:
1197 | | +------+ +-------+
1198 | |------>| A=1 |------ --->| A->0 |
1199 | | +------+ \ +-------+
1200 | CPU 1 | wwwwwwwwwwwwwwww \ --->| B->9 |
1201 | | +------+ | +-------+
1202 | |------>| B=2 |--- | : :
1203 | | +------+ \ | : : +-------+
1204 +-------+ : : \ | +-------+ | |
1205 ---------->| B->2 |------>| |
1206 | +-------+ | CPU 2 |
1207 | | A->0 |------>| |
1216 Sin embargo, si se colocara una barrera de lectura entre la carga de B y la
1217 carga de A en la CPU 2:
1220 ======================= =======================
1223 <barrera de escritura>
1226 <barrera de lectura>
1229 entonces el orden parcial impuesto por la CPU 1 será percibido
1230 correctamente por la CPU 2:
1233 | | +------+ +-------+
1234 | |------>| A=1 |------ --->| A->0 |
1235 | | +------+ \ +-------+
1236 | CPU 1 | wwwwwwwwwwwwwwww \ --->| B->9 |
1237 | | +------+ | +-------+
1238 | |------>| B=2 |--- | : :
1239 | | +------+ \ | : : +-------+
1240 +-------+ : : \ | +-------+ | |
1241 ---------->| B->2 |------>| |
1242 | +-------+ | CPU 2 |
1245 En este punto la barrera ----> \ rrrrrrrrrrrrrrrrr | |
1246 de lectura consigue que \ +-------+ | |
1247 todos los efectos anteriores ---->| A->1 |------>| |
1248 al almacenamiento de B sean +-------+ | |
1249 perceptibles por la CPU 2 : : +-------+
1252 Para ilustrar esto de manera más completa, considere lo que podría pasar si
1253 el código contenía una carga de A a cada lado de la barrera de lectura:
1256 ======================= =======================
1259 <barrera de escritura>
1262 LOAD A [primer load de A]
1263 <rbarrera de lectura>
1264 LOAD A [segundo load de A]
1266 Aunque las dos cargas de A ocurren después de la carga de B, ambas pueden
1267 obtener diferentes valores:
1270 | | +------+ +-------+
1271 | |------>| A=1 |------ --->| A->0 |
1272 | | +------+ \ +-------+
1273 | CPU 1 | wwwwwwwwwwwwwwww \ --->| B->9 |
1274 | | +------+ | +-------+
1275 | |------>| B=2 |--- | : :
1276 | | +------+ \ | : : +-------+
1277 +-------+ : : \ | +-------+ | |
1278 ---------->| B->2 |------>| |
1279 | +-------+ | CPU 2 |
1283 | | A->0 |------>| 1st |
1285 En este punto la barrera ----> \ rrrrrrrrrrrrrrrrr | |
1286 de lectura consigue que \ +-------+ | |
1287 todos los efectos anteriores ---->| A->1 |------>| |
1288 al almacenamiento de B sean +-------+ | |
1289 perceptibles por la CPU 2 : : +-------+
1291 Pero puede ser que la actualización a A desde la CPU 1 se vuelva
1292 perceptible para la CPU 2 antes de que la barrera de lectura se complete de
1296 | | +------+ +-------+
1297 | |------>| A=1 |------ --->| A->0 |
1298 | | +------+ \ +-------+
1299 | CPU 1 | wwwwwwwwwwwwwwww \ --->| B->9 |
1300 | | +------+ | +-------+
1301 | |------>| B=2 |--- | : :
1302 | | +------+ \ | : : +-------+
1303 +-------+ : : \ | +-------+ | |
1304 ---------->| B->2 |------>| |
1305 | +-------+ | CPU 2 |
1309 ---->| A->1 |------>| 1st |
1311 rrrrrrrrrrrrrrrrr | |
1313 | A->1 |------>| 2nd |
1317 La garantía es que la segunda carga siempre dará como resultado A == 1 si
1318 la carga de B resultó en B == 2. No existe tal garantía para la primera
1319 carga de A; esto puede dar como resultado A == 0 o A == 1.
1322 BARRERAS DE MEMORIA DE LECTURA FRENTE A ESPECULACIÓN DE CARGA
1323 -------------------------------------------------------------
1325 Muchas CPU especulan con las cargas: es decir, ven que necesitarán cargar
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
1329 de instrucciones todavía. Esto permite que la instrucción de carga real
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
1335 o simplemente almacenar en caché para su uso posterior.
1340 ======================= =======================
1342 DIVIDE } Instrucciones de división
1343 DIVIDE } tardan mucho en terminar
1346 donde DIVIDE es DIVIDIR. Que podría aparecer como esto:
1350 --->| B->2 |------>| |
1354 La CPU ocupada con la división ---> --->| A->0 |~~~~ | |
1355 especula sobre el LOAD de A +-------+ ~ | |
1359 Una vez completadas las divisiones --> : : ~-->| |
1360 la CPU puede realizar el : : | |
1361 LOAD con efecto inmediato : : +-------+
1364 Colocando una barrera de lectura o una barrera de dependencia de dirección
1365 justo antes de la segundo carga:
1370 ======================= =======================
1374 <rbarrera de lectura>
1377 obligará a reconsiderar cualquier valor obtenido especulativamente en una
1378 medida dependiente del tipo de barrera utilizada. Si no se hizo ningún
1379 cambio en la ubicación de memoria especulada, entonces el valor especulado
1384 --->| B->2 |------>| |
1388 La CPU ocupada con la división ---> --->| A->0 |~~~~ | |
1389 especula sobre el LOAD de A +-------+ ~ | |
1394 rrrrrrrrrrrrrrrr~ | |
1401 pero si había una actualización o una invalidación de otra CPU pendiente,
1402 entonces la especulación será cancelada y el valor recargado:
1406 --->| B->2 |------>| |
1410 La CPU ocupada con la división ---> --->| A->0 |~~~~ | |
1411 especula sobre el LOAD de A +-------+ ~ | |
1416 rrrrrrrrrrrrrrrrr | |
1418 La especulación es descartada ---> --->| A->1 |------>| |
1419 y un valor actualizado +-------+ | |
1420 es conseguido : : +-------+
1422 ATOMICIDAD MULTICOPIA
1423 ---------------------
1425 La atomicidad multicopia es una noción profundamente intuitiva sobre el
1426 orden que no es siempre proporcionada por los sistemas informáticos reales,
1427 a saber, que un determinada store se vuelve visible al mismo tiempo para
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
1430 atomicidad multicopia completa descartaría valiosas optimizaciones
1431 hardware, por lo que una versión más débil conocida como ``otra atomicidad
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
1434 discute esta versión más débil, pero por brevedad lo llamaremos simplemente
1435 ``atomicidad multicopia''.
1437 El siguiente ejemplo demuestra la atomicidad multicopia:
1440 ======================= ======================= =======================
1442 STORE X=1 r1=LOAD X (reads 1) LOAD Y (reads 1)
1443 <barrera general> <barrera de lectura>
1446 Suponga que la carga de la CPU 2 desde X devuelve 1, que luego almacena en
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
1449 a Y precede la carga de la CPU 3 desde Y. Además, las barreras de memoria
1450 garantizan que la CPU 2 ejecuta su carga antes que su almacenamiento, y la
1451 CPU 3 carga desde Y antes de cargar desde X. La pregunta entonces es
1452 "¿Puede la carga de la CPU 3 desde X devolver 0?"
1454 Debido a que la carga de la CPU 3 desde X en cierto sentido viene después
1455 de la carga de la CPU 2, es natural esperar que la carga de la CPU 3 desde
1456 X deba devolver 1. Esta expectativa se deriva de la atomicidad multicopia:
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
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
1462 sean atómicos multicopia.
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
1466 CPU 2 de X devuelve 1 y la carga de la CPU 3 de Y devuelve 1, entonces la
1467 carga de la CPU 3 desde X debe de hecho también devolver 1.
1469 Sin embargo, las dependencias, las barreras de lectura y las barreras de
1470 escritura no siempre son capaces de compensar la atomicidad no multicopia.
1471 Por ejemplo, supongamos que la barrera general de la CPU 2 se elimina del
1472 ejemplo anterior, dejando solo la dependencia de datos que se muestra a
1476 ======================= ======================= =======================
1478 STORE X=1 r1=LOAD X (escribe 1) LOAD Y (lee 1)
1479 <dependencia de datos> <barrera de lectura>
1480 STORE Y=r1 LOAD X (lee 0)
1482 Esta sustitución permite que la atomicidad no multicopia se desenfrene: en
1483 este ejemplo, es perfectamente legal que la carga de la CPU 2 desde X
1484 devuelva 1, la carga de la CPU 3 desde Y devuelva 1, y su carga desde X
1487 El punto clave es que aunque la dependencia de datos de la CPU 2 ordena su
1488 carga y store, no garantiza ordenar el store de la CPU 1. De forma que, si
1489 este ejemplo se ejecuta en un sistema atómico no multicopia donde las CPU 1
1490 y 2 comparten un buffer de almacenamiento o un nivel de caché, la CPU 2
1491 podría tener acceso anticipado de escritura a CPU 1. Por lo tanto, se
1492 requieren barreras generales para garantizar que todas las CPU acurden el
1493 orden combinado de accesos múltiples.
1495 Las barreras generales pueden compensar no solo la atomicidad no
1496 multicopia, pero también pueden generar orden adicional que puede asegurar
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
1499 proporciona este orden adicional, lo que significa que solo se garantiza
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
1508 r0 = smp_load_acquire(&x);
1510 smp_store_release(&y, 1);
1515 r1 = smp_load_acquire(&y);
1518 smp_store_release(&z, 1);
1523 r2 = smp_load_acquire(&z);
1524 smp_store_release(&x, 1);
1534 Dado que cpu0(), cpu1() y cpu2() participan en una cadena de parejas
1535 smp_store_release()/smp_load_acquire(), el siguiente resultado estaría
1538 r0 == 1 && r1 == 1 && r2 == 1
1540 Además, debido a la relación liberación-adquisición entre cpu0() y cpu1(),
1541 cpu1() debe ver las escrituras de cpu0(), de modo que el siguiente
1542 resultado estaría prohibido:
1546 Sin embargo, el orden proporcionado por una cadena de
1547 liberación-adquisición es local a las CPU que participan en esa cadena y no
1548 se aplica a cpu3(), al menos aparte de los stores. Por lo tanto, es posible
1549 el siguiente resultado:
1551 r0 == 0 && r1 == 1 && r2 == 1 && r3 == 0 && r4 == 0
1553 Por otro lado, también el siguiente resultado es posible:
1555 r0 == 0 && r1 == 1 && r2 == 1 && r3 == 0 && r4 == 0 && r5 == 1
1557 Aunque cpu0(), cpu1() y cpu2() verán sus respectivas lecturas y escrituras
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
1560 de que las instrucciones de barrera de memoria débiles utilizadas para
1561 implementar smp_load_acquire() y smp_store_release() no son necesarios para
1562 ordenar stores anteriores contra cargas posteriores en todos los casos.
1563 Esto significa que cpu3() puede ver el store de cpu0() suceder -después- de
1564 la carga de cpu1() desde v, aunque tanto cpu0() como cpu1() están de
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
1570 siguiente resultados son posibles:
1572 r0 == 0 && r1 == 0 && r2 == 0 && r5 == 0
1574 Tenga en cuenta que este resultado puede ocurrir incluso en un mítico
1575 sistema, consistente en secuencia, donde nunca se reordena nada.
1577 Para reiterar, si su código requiere un orden completo de todas las
1578 operaciones, utilice barreras generales en todo momento.
1581 ==============================
1582 BARRERAS EXPLÍCITAS DEL KERNEL
1583 ==============================
1585 El kernel Linux tiene una variedad de diferentes barreras que actúan a
1588 (*) Barrera del compilador.
1590 (*) Barreras de memoria de la CPU.
1593 BARRERA DEL COMPILADOR
1594 -----------------------
1596 El kernel de Linux tiene una función de barrera del compilador explícita
1597 que evita que el el compilador mueva los accesos a la memoria de cualquier
1602 Esta es una barrera general: no hay variantes de barrier() para casos de
1603 lectura-lectura o escritura-escritura. Sin embargo, READ_ONCE() y
1604 WRITE_ONCE() pueden ser considerado como formas débiles de barrier() que
1605 afectan solo específicos accesos marcados por READ_ONCE() o WRITE_ONCE().
1607 La función barrier() produce los siguientes efectos:
1609 (*) Evita que el compilador reordene los accesos tras barrier() para
1610 preceder a cualquier acceso que preceda a barrier(). Un ejemplo de uso
1611 de esta propiedad es facilitar la comunicación entre código del
1612 interrupt-handler (encargo de gestionar interrupciones) y el código
1613 que fue interrumpido.
1615 (*) Dentro de un bucle ("loop"), obliga al compilador a cargar las
1616 variables utilizadas en ese loop condicional en cada paso a través de
1619 Las funciones READ_ONCE() y WRITE_ONCE() pueden evitar cualquier cantidad
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
1622 algunos ejemplos de tal tipo de optimizaciones:
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
1626 derecho de reordenar cargas a la misma variable. Esto significa que
1627 el siguiente código:
1632 Podría resultar en un valor más antiguo de x almacenado en a[1] que en
1633 a[0]. Evite que tanto el compilador como la CPU hagan esto de la
1636 a[0] = READ_ONCE(x);
1637 a[1] = READ_ONCE(x);
1639 En resumen, READ_ONCE() y WRITE_ONCE() proporcionan coherencia de
1640 caché para accesos desde múltiples CPUs a una sola variable.
1642 (*) El compilador tiene derecho a juntar cargas sucesivas de la misma
1643 variable. Tal fusión puede hacer que el compilador "optimice" el
1647 hacer_algo_con(tmp);
1649 en el siguiente código, que, aunque en cierto sentido es legítimo
1650 para un código de un solo subproceso, es casi seguro que no es lo
1651 que el desarrollador pretendía:
1655 hacer_algo_con(tmp);
1657 Use READ_ONCE() para evitar que el compilador le haga esto:
1659 while (tmp = READ_ONCE(a))
1660 hacer_algo_con(tmp);
1662 (*) El compilador tiene derecho a recargar una variable, por ejemplo,
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
1665 compilador podría por lo tanto, optimizar la variable 'tmp' de nuestro
1669 hacer_algo_con(tmp);
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
1680 modificada por alguna otra CPU, entre la instrucción "while" y la
1681 llamada a hacer_algo_con().
1683 De nuevo, use READ_ONCE() para evitar que el compilador haga esto:
1685 while (tmp = READ_ONCE(a))
1686 hacer_algo_con(tmp);
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
1690 este guardado y posterior restauración es por lo que los compiladores
1691 recargan las variables. Hacerlo es perfectamente seguro para código de
1692 subproceso único, por lo que debe informar al compilador sobre los
1693 casos donde no sea seguro.
1695 (*) El compilador está en su derecho de omitir una carga por completo si
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
1701 hacer_algo_con(tmp);
1707 Esta transformación es una victoria para un código de un solo
1708 subproceso, porque se deshace de una carga y un branch. El problema es
1709 que el compilador llevará a cabo su prueba asumiendo que la CPU actual
1710 es la única actualizando la variable 'a'. Si la variable 'a' es
1711 compartida, entonces la prueba del compilador será errónea. Use
1712 READ_ONCE() para decirle al compilador que no sabe tanto como cree:
1714 while (tmp = READ_ONCE(a))
1715 hacer_algo_con(tmp);
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
1719 READ_ONCE(). Por ejemplo, suponga que Ud. hace lo siguiente y MAX es
1720 una macro de preprocesador con el valor 1:
1722 while ((tmp = READ_ONCE(a)) % MAX)
1723 hacer_algo_con(tmp);
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
1734 algo incorrecto para las variables compartidas. Por ejemplo, suponga
1735 que tiene lo siguiente:
1738 ... Código que no almacena la variable a ...
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
1743 sorpresa, si alguna otra CPU hubiera almacenado la variable 'a'
1746 Use WRITE_ONCE() para evitar que el compilador haga este tipo de
1747 suposición equivocada:
1750 ... Código que no almacena la variable a ...
1753 (*) El compilador tiene derecho a reordenar los accesos a memoria a menos
1754 que le diga que no. Por ejemplo, considere la siguiente interacción
1755 entre el código de nivel de proceso y un controlador de interrupción:
1757 void nivel_de_procesamiento(void)
1759 msg = ACQUIRE_mensaje();
1763 void controlador_interrupcion(void)
1766 procesar_mensaje(msg);
1769 No hay nada que impida que el compilador transforme
1770 nivel_de_procesamiento() a lo siguiente, que de hecho, bien podría ser
1771 una victoria para código de un solo subproceso:
1773 void nivel_de_procesamiento(void)
1776 msg = ACQUIRE_mensaje();
1779 Si la interrupción ocurre entre estas dos declaraciones, entonces
1780 controlador_interrupcion() podría recibir un mensaje ilegible. Use
1781 READ_ONCE() para evitar esto de la siguiente manera:
1783 void nivel_de_procesamiento(void)
1785 WRITE_ONCE(msg, ACQUIRE_mensaje());
1786 WRITE_ONCE(flag, true);
1789 void controlador_interrupcion(void)
1791 if (READ_ONCE(flag))
1792 procesar_mensaje(READ_ONCE(msg));
1795 Tenga en cuenta que los envoltorios ("wrappers") READ_ONCE() y
1796 WRITE_ONCE() en controlador_interrupcion() son necesarios si este
1797 controlador de interrupciones puede ser interrumpido por algo que
1798 también accede a 'flag' y 'msg', por ejemplo, una interrupción anidada
1799 o un NMI. De lo contrario, READ_ONCE() y WRITE_ONCE() no son
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
1803 hecho, si un controlador de interrupciones regresa con interrupciones
1804 habilitadas, obtendrá un WARN_ONCE().)
1806 Debe suponer que el compilador puede mover READ_ONCE() y WRITE_ONCE()
1807 a código que no contiene READ_ONCE(), WRITE_ONCE(), barrier(), o
1808 primitivas similares.
1810 Este efecto también podría lograrse usando barrier(), pero READ_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
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
1817 ocurren READ_ONCE() y WRITE_ONCE(), aunque la CPU, efectivamente, no
1820 (*) El compilador tiene derecho a inventar stores para una variable,
1821 como en el siguiente ejemplo:
1828 El compilador podría ahorrar un branch al optimizar esto de la
1835 En el código de un solo subproceso, esto no solo es seguro, sino que
1836 también ahorra un branch. Desafortunadamente, en código concurrente,
1837 esta optimización podría causar que alguna otra CPU vea un valor falso
1838 de 42, incluso si la variable 'a' nunca fue cero, al cargar la
1839 variable 'b'. Use WRITE_ONCE() para evitar esto de la siguiente
1847 El compilador también puede inventar cargas. Estos casos suelen ser
1848 menos perjudiciales, pero pueden dar como resultado "bouncing" de la
1849 línea de caché y, por lo tanto, bajo rendimiento y escalabilidad.
1850 Utilice READ_ONCE() para evitar cargas inventadas.
1852 (*) Para ubicaciones de memoria alineadas cuyo tamaño les permita
1853 acceder con una sola instrucción de referencia de memoria, evite el
1854 "desgarro de la carga" (load tearing) y "desgarro del store" (store
1855 tearing), en el que un solo gran acceso es reemplazado por múltiples
1856 accesos menores. Por ejemplo, dada una arquitectura que tiene
1857 instrucciones de almacenamiento de 16 bits con campos inmediatos de 7
1858 bits, el compilador podría tener la tentación de usar dos
1859 instrucciones inmediatas de almacenamiento de 16 bits para implementar
1860 el siguiente store de 32 bits:
1864 Tenga en cuenta que GCC realmente usa este tipo de optimización, lo
1865 cual no es sorprendente dado que probablemente costaría más de dos
1866 instrucciones el construir la constante y luego almacenarla. Por lo
1867 tanto, esta optimización puede ser una victoria en un código de un
1868 solo subproceso. De hecho, un error reciente (desde que se solucionó)
1869 hizo que GCC usara incorrectamente esta optimización en un store
1870 volátil. En ausencia de tales errores, el uso de WRITE_ONCE() evita el
1871 desgarro del store en el siguiente ejemplo:
1873 struct __attribute__((__packed__)) foo {
1878 struct foo foo1, foo2;
1885 Debido a que no hay envoltorios READ_ONCE() o WRITE_ONCE() y no
1886 hay markings volátiles, el compilador estaría en su derecho de
1887 implementar estas tres declaraciones de asignación como un par de
1888 cargas de 32 bits, seguido de un par de stores de 32 bits. Esto
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
1894 WRITE_ONCE(foo2.b, READ_ONCE(foo1.b));
1897 Aparte de esto, nunca es necesario usar READ_ONCE() y WRITE_ONCE() en una
1898 variable que se ha marcado como volátil. Por ejemplo, dado que 'jiffies'
1899 está marcado como volátil, nunca es necesario usar READ_ONCE(jiffies). La
1900 razón de esto es que READ_ONCE() y WRITE_ONCE() se implementan como
1901 conversiones volátiles, lo que no tiene efecto cuando su argumento ya está
1902 marcado como volátil.
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.
1908 BARRERAS DE MEMORIA DE LA CPU
1909 -----------------------------
1911 El kernel de Linux tiene siete barreras básicas de memoria de CPU:
1913 TIPO OBLIGATORIO SMP CONDICIONAL
1914 ======================= =============== ===============
1915 GENERAL mb() smp_mb()
1916 WRITE wmb() smp_wmb()
1917 READ rmb() smp_rmb()
1918 DEPEDENCIA DE DIRECCIÓN READ_ONCE()
1921 Todas las barreras de memoria, excepto las barreras de dependencia de
1922 direcciones, implican una barrera del compilador. Las dependencias de
1923 direcciones no imponen ningún orden de compilación adicional.
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
1931 que un compilador vuelva a cargar b después de haber cargado a[b], teniendo
1932 así una copia más nueva de b que a[b]. Aún no se ha conseguido un consenso
1933 acerca de estos problemas, sin embargo, el macro READ_ONCE() es un buen
1934 lugar para empezar a buscar.
1936 Las barreras de memoria SMP se reducen a barreras de compilador cuando se
1937 compila a monoprocesador, porque se supone que una CPU parecerá ser
1938 auto-consistente, y ordenará correctamente los accesos superpuestos
1939 respecto a sí misma. Sin embargo, consulte la subsección "Guests de
1940 máquinas virtuales" mas adelante.
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.
1946 Las barreras obligatorias no deben usarse para controlar los efectos de
1947 SMP, ya que dichas barreras imponen una sobrecarga innecesaria en los
1948 sistemas SMP y UP. Se pueden, sin embargo, usar para controlar los efectos
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
1952 prohibir tanto al compilador como a la CPU que sean reordenados.
1955 Hay algunas funciones de barrera más avanzadas:
1957 (*) smp_store_mb(var, valor)
1959 Asigna el valor a la variable y luego inserta una barrera de memoria
1960 completa después de ella. No se garantiza insertar nada más que una
1961 barrera del compilador en una compilación UP.
1964 (*) smp_mb__before_atomic();
1965 (*) smp_mb__after_atomic();
1967 Estos se pueden usar con funciones RMW atómicas que no implican
1968 barreras de memoria, pero donde el código necesita una barrera de
1969 memoria. Ejemplos de funciones RMW atómicas que no implican una
1970 barrera de memoria son, por ejemplo, agregar, restar, operaciones
1971 condicionales (fallidas), funciones _relaxed, pero no atomic_read o
1972 atomic_set. Un ejemplo común donde se puede requerir una barrera es
1973 cuando se usan operaciones atómicas como referencia de contador.
1975 Estos también se utilizan para funciones atómicas RMW bitop que no
1976 implican una barrera de memoria (como set_bit y clear_bit).
1978 Como ejemplo, considere una pieza de código que marca un objeto como
1979 muerto y luego disminuye el contador de referencias del objeto:
1982 smp_mb__before_atomic();
1983 atomic_dec(&obj->ref_count);
1985 Esto asegura que la marca de muerte en el objeto se perciba como
1986 fijada *antes* de que disminuya el contador de referencia.
1988 Consulte Documentation/atomic_{t,bitops}.txt para obtener más
1996 Estos son usados con memoria consistente para garantizar el orden de
1997 escrituras o lecturas de memoria compartida accesible tanto para la
1998 CPU como para un dispositivo compatible con DMA.
2000 Por ejemplo, considere un controlador de dispositivo que comparte
2001 memoria con otro dispositivo y usa un valor de estado del descriptor
2002 para indicar si el descriptor pertenece al dispositivo o a la CPU, y
2003 un "doorbell" (timbre, punto de acceso) para avisarle cuando haya
2004 nuevos descriptores disponibles:
2006 if (desc->status != DEVICE_OWN) {
2007 /* no leer los datos hasta que tengamos el descriptor */
2010 /* leer/modificar datos */
2011 read_data = desc->data;
2012 desc->data = write_data;
2014 /* flush de modificaciones antes de la actualización de estado */
2017 /* asignar propiedad */
2018 desc->status = DEVICE_OWN;
2020 /* notificar al dispositivo de nuevos descriptores */
2021 writel(DESC_NOTIFY, doorbell);
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()
2028 implica tanto un dma_rmb() como un dma_wmb(). Tenga en cuenta que, al
2029 usar writel(), no se necesita un wmb() anterior para garantizar que
2030 las escrituras de la memoria caché coherente se hayan completado antes
2031 escribiendo a la región MMIO. El writel_relaxed() más barato no
2032 proporciona esta garantía y no debe utilizarse aquí.
2034 Consulte la subsección "Efectos de barrera de E/S del kernel" para
2035 obtener más información sobre accesorios de E/S relajados y el archivo
2036 Documentation/core-api/dma-api.rst para más información sobre memoria
2041 Es es para uso con memoria persistente para garantizar que los stores
2042 para los que las modificaciones se escriben en el almacenamiento
2043 persistente llegaron a dominio de durabilidad de la plataforma.
2045 Por ejemplo, después de una escritura no temporal en la región pmem,
2046 usamos pmem_wmb() para garantizar que los stores hayan alcanzado el
2047 dominio de durabilidad de la plataforma. Esto garantiza que los stores
2048 han actualizado el almacenamiento persistente antes de cualquier
2049 acceso a datos o transferencia de datos causada por instrucciones
2050 posteriores. Esto es además del orden realizado por wmb().
2052 Para la carga desde memoria persistente, las barreras de memoria de
2053 lectura existentes son suficientes para garantizar el orden de
2058 Para accesos a memoria con atributos de combinación de escritura (por
2059 ejemplo, los devueltos por ioremap_wc(), la CPU puede esperar a que
2060 los accesos anteriores se junten con posteriores. io_stop_wc() se
2061 puede utilizar para evitar la combinación de accesos a memoria de
2062 de escritura antes de esta macro, con los posteriores, cuando dicha
2063 espera tenga implicaciones en el rendimiento.
2065 =========================================
2066 BARRERAS DE MEMORIA IMPLÍCITAS DEL KERNEL
2067 =========================================
2069 Algunas de las otras funciones en el kernel Linux implican barreras de
2070 memoria, entre estas encontramos funciones de bloqueo y planificación
2073 Esta especificación es una garantía _mínima_; cualquier arquitectura
2074 particular puede proporcionar garantías más sustanciales, pero no se puede
2075 confiar en estas fuera de código específico de arquitectura.
2078 FUNCIONES DE ADQUISICIÓN DE CERROJO
2079 -----------------------------------
2081 El kernel Linux tiene una serie de abstracciones de bloqueo:
2083 (*) spin locks (cerrojos en loop)
2084 (*) R/W spin lock (cerrojos de escritura/lectura)
2089 En todos los casos existen variantes de las operaciones "ACQUIRE" y
2090 "RELEASE" para cada uno de ellos. Todas estas operaciones implican ciertas
2093 (1) Implicaciones de la operación ACQUIRE:
2095 Las operaciones de memoria emitidas después del ACQUIRE se completarán
2096 después de que la operación ACQUIRE haya finalizado.
2098 Las operaciones de memoria emitidas antes de ACQUIRE pueden
2099 completarse después que la operación ACQUIRE se ha completado.
2101 (2) Implicaciones de la operación RELEASE:
2103 Las operaciones de memoria emitidas antes de la RELEASE se
2104 completarán antes de que la operación de RELEASE se haya completado.
2106 Las operaciones de memoria emitidas después de la RELEASE pueden
2107 completarse antes de que la operación de RELEASE se haya completado.
2109 (3) Implicación de ACQUIRE vs ACQUIRE:
2111 Todas las operaciones ACQUIRE emitidas antes de otra operación
2112 ACQUIRE serán completadas antes de esa operación ACQUIRE.
2114 (4) Implicación de ACQUIRE vs RELEASE:
2116 Todas las operaciones ACQUIRE emitidas antes de una operación RELEASE
2117 serán completadas antes de la operación RELEASE.
2119 (5) Implicación de ACQUIRE condicional fallido:
2121 Ciertas variantes de bloqueo de la operación ACQUIRE pueden fallar, ya
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
2124 cerrojo estuviera disponible. Los fallos en cerrojos no implican
2125 ningún tipo de barrera.
2127 [!] Nota: una de las consecuencias de que los cerrojos en ACQUIRE y RELEASE
2128 sean barreras unidireccionales, es que los efectos de las instrucciones
2129 fuera de una sección crítica pueden filtrarse al interior de la sección
2132 No se puede suponer que un ACQUIRE seguido de una RELEASE sea una barrera
2133 de memoria completa dado que es posible que un acceso anterior a ACQUIRE
2134 suceda después del ACQUIRE, y un acceso posterior a la RELEASE suceda antes
2135 del RELEASE, y los dos accesos puedan entonces cruzarse:
2144 ACQUIRE M, STORE *B, STORE *A, RELEASE M
2146 Cuando ACQUIRE y RELEASE son bloqueo de adquisición y liberación,
2147 respectivamente, este mismo orden puede ocurrir si el cerrojo ACQUIRE y
2148 RELEASE son para la misma variable de bloqueo, pero solo desde la
2149 perspectiva de otra CPU que no tiene ese bloqueo. En resumen, un ACQUIRE
2150 seguido de un RELEASE NO puede entenderse como una barrera de memoria
2153 De manera similar, el caso inverso de un RELEASE seguido de un ACQUIRE no
2154 implica una barrera de memoria completa. Por lo tanto, la ejecución de la
2155 CPU de los tramos críticos correspondientes a la RELEASE y la ACQUIRE
2156 pueden cruzarse, de modo que:
2165 ACQUIRE N, STORE *B, STORE *A, RELEASE M
2167 Podría parecer que este nuevo orden podría introducir un punto muerto.
2168 Sin embargo, esto no puede suceder porque si tal punto muerto amenazara
2169 con suceder, el RELEASE simplemente se completaría, evitando así el
2170 interbloqueo ("deadlock", punto muerto).
2172 ¿Por qué funciona esto?
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
2176 desarrollador) cambió las operaciones, un deadlock -podría- ocurrir.
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
2180 simplemente eligió intentar ejecutar primero la última operación de
2181 bloqueo. Si hay un interbloqueo, esta operación de bloqueo simplemente
2182 esperará (o tratará de dormir, pero hablaremos de eso más adelante). La
2183 CPU eventualmente ejecutará la operación de desbloqueo (que precedió a la
2184 operación de bloqueo en el código ensamblador), lo que desenmascará el
2185 potencial punto muerto, permitiendo que la operación de bloqueo tenga
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
2190 encontrará una barrera de memoria, que forzará la operación de desbloqueo
2191 anterior para completar, nuevamente desentrañando el punto muerto. Podría
2192 haber una carrera de desbloqueo del sueño ("sleep-unlock race"), pero la
2193 primitiva de bloqueo necesita resolver tales carreras correctamente en
2196 Es posible que los cerrojos y los semáforos no proporcionen ninguna
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,
2199 especialmente con respecto a los accesos de E/S, a menos que se combinen
2200 con operaciones de inhabilitación de interrupciones.
2202 Consulte también la sección "Efectos de barrera adquiriendo intra-CPU".
2205 Como ejemplo, considere lo siguiente:
2216 La siguiente secuencia de eventos es aceptable:
2218 ACQUIRE, {*F,*A}, *E, {*C,*D}, *B, RELEASE
2220 [+] Tenga en cuenta que {*F,*A} indica un acceso combinado.
2222 Pero ninguno de los siguientes lo son:
2224 {*F,*A}, *B, ACQUIRE, *C, *D, RELEASE, *E
2225 *A, *B, *C, ACQUIRE, *D, RELEASE, *E, *F
2226 *A, *B, ACQUIRE, *C, RELEASE, *D, *E, *F
2227 *B, ACQUIRE, *C, *D, RELEASE, {*F,*A}, *E
2231 FUNCIONES DE DESACTIVACIÓN DE INTERRUPCIONES
2232 --------------------------------------------
2234 Las funciones que deshabilitan interrupciones (equivalentes a ACQUIRE) y
2235 habilitan interrupciones (equivalentes a RELEASE) actuarán únicamente como
2236 barrera del compilador. Por consiguiente, si la memoria o la E/S requieren
2237 barreras en tal situación, deben ser provistas por algún otro medio.
2240 FUNCIONES DE DORMIR Y DESPERTAR
2241 -------------------------------
2243 Dormir y despertar son eventos marcados ("flagged") en los datos globales
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
2248 a dormir, y las primitivas para iniciar un despertar implican ciertas
2251 En primer lugar, el agente durmiente normalmente sigue algo similar a esta
2252 secuencia de eventos:
2255 set_current_state(TASK_UNINTERRUPTIBLE);
2256 if (evento_indicado)
2258 schedule(); // planificar
2261 Una barrera de memoria general se obtiene automáticamente mediante
2262 set_current_state() después de haber alterado el estado de la tarea:
2265 ===============================
2266 set_current_state(); // hacer_estado_actual()
2268 STORE current->state
2270 LOAD evento_indicado
2272 set_current_state() puede estar envuelto por:
2274 prepare_to_wait(); // preparese_para_esperar();
2275 prepare_to_wait_exclusive(); // prepararse_para_solo_esperar();
2277 que por lo tanto también implican una barrera de memoria general después de
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
2283 wait_event_interruptible();
2284 wait_event_interruptible_exclusive();
2285 wait_event_interruptible_timeout();
2286 wait_event_killable();
2287 wait_event_timeout();
2292 En segundo lugar, el código que realiza una activación normalmente se
2293 asemeja a algo como esto:
2295 evento_indicado = 1;
2296 wake_up(&event_wait_queue); // despertar
2300 evento_indicado = 1;
2301 wake_up_process(event_daemon); // despertar proceso
2303 wake_up() ejecuta una barrera de memoria general si despierta algo. Si no
2304 despierta nada, entonces una barrera de memoria puede o no ser ejecutada;
2305 no debe confiar en ello. La barrera se produce antes del acceso al estado
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):
2309 CPU 1 (Durmiente) CPU 2 (Despertadora)
2310 =============================== ===============================
2311 set_current_state(); STORE evento_indicado
2312 smp_store_mb(); wake_up();
2313 STORE current->state ...
2314 <barrera general> <barrera general>
2315 LOAD evento_indicado if ((LOAD task->state) & TASK_NORMAL)
2318 donde "task" es el subproceso que se está despertando y es igual al
2319 "current" (hilo actual) de la CPU 1.
2321 Para reiterar, se garantiza la ejecución de una barrera de memoria general
2322 mediante wake_up() si algo está realmente despierto, pero de lo contrario
2323 no existe tal garantía. Para entender esto, considere la siguiente
2324 secuencia de eventos, donde X e Y son ambos cero inicialmente:
2327 =============================== ===============================
2329 smp_mb(); wake_up();
2332 Si ocurre una reactivación ("wakeup"), una (al menos) de las dos cargas
2333 debe ver 1. Si, por otro lado, no ocurre una reactivación, ambas cargas
2336 wake_up_process() siempre ejecuta una barrera de memoria general. La
2337 barrera, de nuevo, ocurre antes de que se acceda al estado del hilo. En
2338 particular, si wake_up(), en el fragmento anterior, fuera reemplazado por
2339 una llamada a wake_up_process(), las dos cargas verían 1, garantizado.
2341 Las funciones de activación disponibles incluyen:
2347 wake_up_interruptible();
2348 wake_up_interruptible_all();
2349 wake_up_interruptible_nr();
2350 wake_up_interruptible_poll();
2351 wake_up_interruptible_sync();
2352 wake_up_interruptible_sync_poll();
2354 wake_up_locked_poll();
2359 En términos de orden de la memoria, todas estas funciones proporcionan las
2360 mismas garantías que un wake_up() (o más fuertes).
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:
2367 set_current_state(TASK_INTERRUPTIBLE);
2368 if (evento_indicado)
2370 __set_current_state(TASK_RUNNING);
2371 hacer_algo(my_data);
2373 y el que despierta hace:
2376 evento_indicado = 1;
2377 wake_up(&event_wait_queue);
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
2383 anterior debería hacer:
2385 set_current_state(TASK_INTERRUPTIBLE);
2386 if (evento_indicado) {
2388 hacer_algo(my_data);
2391 y el que despierta debería hacer:
2395 evento_indicado = 1;
2396 wake_up(&event_wait_queue);
2401 Otras funciones que implican barreras:
2403 (*) schedule() y similares implican barreras completas de memoria.
2406 ========================================
2407 EFECTOS DE BARRERA ADQUIRIENDO INTRA-CPU
2408 ========================================
2410 En los sistemas SMP, las primitivas de bloqueo proveen una forma más
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
2416 ADQUISICIÓN VS ACCESOS A MEMORIA
2417 --------------------------------
2419 Considere lo siguiente: el sistema tiene un par de spinlocks (M) y (Q), y
2420 tres CPU; entonces la siguiente secuencia de eventos debería ocurrir:
2423 =============================== ===============================
2424 WRITE_ONCE(*A, a); WRITE_ONCE(*E, e);
2426 WRITE_ONCE(*B, b); WRITE_ONCE(*F, f);
2427 WRITE_ONCE(*C, c); WRITE_ONCE(*G, g);
2429 WRITE_ONCE(*D, d); WRITE_ONCE(*H, h);
2431 Entonces no hay garantía sobre en qué orden verá la CPU 3 los accesos a *A
2432 hasta que *H ocurra, además de las restricciones impuestas por los bloqueos
2433 separados en las distintas CPUs. Podría, por ejemplo, ver:
2435 *E, ACQUIRE M, ACQUIRE Q, *G, *C, *F, *A, *B, RELEASE Q, *D, *H, RELEASE M
2437 Pero no verá ninguno de:
2439 *B, *C or *D preceding ACQUIRE M
2440 *A, *B or *C following RELEASE M
2441 *F, *G or *H preceding ACQUIRE Q
2442 *E, *F or *G following RELEASE Q
2444 ========================================
2445 ¿DÓNDE SE NECESITAN BARRERAS DE MEMORIA?
2446 ========================================
2448 Bajo operación normal, el re-ordenamiento de una operación de memoria
2449 generalmente no va a suponer un problema, ya que para una pieza de código
2450 lineal de un solo subproceso seguirá pareciendo que funciona correctamente,
2451 incluso si está en un kernel SMP. Existen, sin embargo, cuatro
2452 circunstancias en las que reordenar definitivamente _podría_ ser un
2455 (*) Interacción entre procesadores.
2457 (*) Operaciones atómicas.
2459 (*) Acceso a dispositivos.
2464 INTERACCIÓN ENTRE PROCESADORES
2465 ------------------------------
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
2469 tiempo. Esto puede causar problemas de sincronización, y la forma habitual
2470 de tratar con estos es utilizar cerrojos. Sin embargo, los cerrojos son
2471 bastante caros, por lo que puede ser preferible operar sin el uso de un
2472 cerrojo a ser posible. En cuyo caso, es posible que las operaciones que
2473 afectan a ambas CPU deban ordenarse cuidadosamente para evitar un
2474 funcionamiento incorrecto.
2476 Considere, por ejemplo, la ruta lenta del semáforo R/W. Aquí hay un proceso
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:
2480 struct rw_semaphore {
2483 struct list_head waiters;
2486 struct rwsem_waiter {
2487 struct list_head list;
2488 struct task_struct *task;
2491 Para despertar a un proceso que espera ("waiter") en particular, las
2492 funciones up_read() o up_write() tienen que:
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
2502 (4) llamar a wake_up_process() en la tarea; y
2504 (5) liberar la referencia retenida en la estructura de tareas del waiter.
2506 En otras palabras, tiene que realizar esta secuencia de eventos:
2508 LOAD waiter->list.next;
2514 y si alguno de estos pasos ocurre fuera de orden, entonces todo puede que
2515 funcione defectuosamente.
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.
2526 Considere entonces lo que podría suceder con la secuencia de eventos
2530 =============================== ===============================
2532 Poner waiter en la "queue" (cola)
2537 Despertado por otro evento
2539 Reanudar el procesamiento
2542 foo() estropea *waiter
2544 LOAD waiter->list.next;
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.
2551 La forma de lidiar con esto es insertar una barrera de memoria SMP general:
2553 LOAD waiter->list.next;
2560 En este caso, la barrera garantiza que todos los accesos a memoria antes de
2561 la barrera parecerán suceder antes de todos los accesos a memoria después
2562 de dicha barrera con respecto a las demás CPU del sistema. _No_ garantiza
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.
2566 En un sistema UP, donde esto no sería un problema, la función smp_mb() es
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
2569 CPU. Como solo hay un CPU, la lógica de orden de dependencias de esa CPU se
2570 encargará de todo lo demás.
2573 OPERACIONES ATÓMICAS
2574 --------------------
2576 Si bien son, técnicamente, consideraciones de interacción entre
2577 procesadores, las operaciones atómicas se destacan especialmente porque
2578 algunas de ellas implican barreras de memoria completa y algunas otras no,
2579 pero se confía mucho en ellos en su conjunto a lo largo del kernel.
2581 Consulte Documentation/atomic_t.txt para obtener más información.
2584 ACCESO A DISPOSITIVOS
2585 ---------------------
2587 Un driver puede ser interrumpido por su propia rutina de servicio de
2588 interrupción y, por lo tanto, las dos partes del driver pueden interferir
2589 con los intentos de controlar o acceder al dispositivo.
2591 Esto puede aliviarse, al menos en parte, desactivando las interrupciones
2592 locales (una forma de bloqueo), de modo que las operaciones críticas sean
2593 todas contenidas dentro la sección de interrupción desactivada en el
2594 controlador. Mientras la interrupción del driver está ejecutando la rutina,
2595 es posible que el "core" del controlador no se ejecute en la misma CPU y no
2596 se permita que su interrupción vuelva a ocurrir hasta que la interrupción
2597 actual haya sido resuelta, por lo tanto, el controlador de interrupción no
2598 necesita bloquearse contra esto.
2600 Sin embargo, considere un driver que estaba hablando con una tarjeta
2601 ethernet que tiene un registro de direcciones y un registro de datos. Si
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
2606 IRQ LOCALES DESACTIVADAS
2609 IRQ LOCALES ACTIVADAS
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
2617 suficientemente relajadas:
2619 STORE *ADDR = 3, STORE *ADDR = 4, STORE *DATA = y, q = LOAD *DATA
2621 Si se relajan las reglas de orden, se debe asumir que los accesos
2622 realizados dentro de la sección con interrupción deshabilitada pueden
2623 filtrarse fuera de esta y pueden intercalarse con accesos realizados en una
2624 interrupción - y viceversa - a menos que se utilicenn barreras implícita o
2627 Normalmente, esto no será un problema porque los accesos de E/S realizados
2628 dentro de tales secciones incluirán operaciones de carga síncronas en
2629 registros E/S estrictamente ordenados, que forman barreras de E/S
2633 Una situación similar puede ocurrir entre una rutina de interrupción y dos
2634 rutinas ejecutándose en separadas CPU que se comunican entre sí. Si tal
2635 caso es probable, entonces se deben usar bloqueos de desactivación de
2636 interrupciones para garantizar el orden.
2639 =====================================
2640 Efectos de barrera de E/S del kernel
2641 =====================================
2643 La interfaz con periféricos a través de accesos de E/S es profundamente
2644 específica para cada arquitectura y dispositivo. Por lo tanto, los drivers
2645 que son inherentemente no portátiles pueden depender de comportamientos
2646 específicos de sus sistemas de destino, con el fin de lograr la
2647 sincronización de la manera más ligera posible. Para drivers que deseen ser
2648 portátiles entre múltiples arquitecturas e implementaciones de bus, el
2649 kernel ofrece una serie de funciones de acceso que proporcionan varios
2650 grados de garantías de orden:
2652 (*) readX(), writeX():
2654 Las funciones de acceso MMIO readX() y writeX() usan un puntero al
2655 periférico al que se accede como un parámetro __iomem *. para punteros
2656 asignados los atributos de E/S predeterminados (por ejemplo, los
2657 devueltos por ioremap()), las garantías de orden son las siguientes:
2659 1. Se ordenan todos los accesos readX() y writeX() a un mismo periférico
2660 entre estos. Esto asegura que los registros de acceso MMIO por el
2661 mismo subproceso de la CPU a un dispositivo en particular llegarán en
2662 el orden del programa.
2664 2. Se ordena un writeX() emitido por un subproceso de CPU que contiene un
2665 spinlock antes de un writeX() al mismo periférico desde otro
2666 subproceso de CPU, si emitido después de una adquisición posterior del
2667 mismo spinlock. Esto garantiza que ese registro MMIO escribe en un
2668 dispositivo en particular, mientras que se obtiene un spinlock en un
2669 orden consistente con las adquisiciones del cerrojo.
2671 3. Un writeX() por un subproceso de la CPU al periférico primero esperará
2672 a la finalización de todas las escrituras anteriores en la memoria
2673 emitidas por, o bien propagadas por, el mismo subproceso. Esto asegura
2674 que las escrituras de la CPU a un búfer DMA de salida asignadas por
2675 dma_alloc_coherent() serán visibles para un motor ("engine") DMA
2676 cuando la CPU escriba en sus registros de control MMIO, para activar
2679 4. Un readX() de un subproceso del CPU, desde el periférico, se
2680 completará antes de que cualquier lectura subsiguiente de memoria por
2681 el mismo subproceso pueda comenzar. Esto asegura que las lecturas de
2682 la CPU desde un búfer DMA entrantes asignadas por
2683 dma_alloc_coherent(), no verán datos obsoletos después de leer el
2684 registro de estado MMIO del motor DMA, para establecer que la
2685 transferencia DMA se haya completado.
2687 5. Un readX() por un subproceso del CPU, desde el periférico, se
2688 completará antes de que cualquier bucle delay() subsiguiente pueda
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
2691 con 1us de diferencia, si la primera escritura se lee inmediatamente
2692 de vuelta con readX() y se llama a udelay(1) antes del segundo
2695 writel(42, DEVICE_REGISTER_0); // Llega al dispositivo ...
2696 readl(DEVICE_REGISTER_0);
2698 writel(42, DEVICE_REGISTER_1); // al menos 1us antes de esto....
2700 Las propiedades de orden de los punteros __iomem obtenidos con valores de
2701 atributos que no sean los valores por defecto (por ejemplo, los devueltos
2702 por ioremap_wc()) son específicos de la arquitectura subyacente y, por lo
2703 tanto, las garantías enumeradas anteriormente no pueden por lo general ser
2704 aseguradas para accesos a este tipo de "mappings" (asignaciones).
2706 (*) readX_relaxed(), writeX_relaxed():
2708 Son similares a readX() y writeX(), pero proporcionan una garantía de
2709 orden de memoria más débil. Específicamente, no garantizan orden con
2710 respecto al bloqueo, los accesos normales a la memoria o los bucles
2711 delay() (es decir, los puntos 2-5 arriba) pero todavía se garantiza que
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
2714 valor predeterminado para los atributos de E/S.
2716 (*) readsX(), writesX():
2718 Los puntos de entrada readsX() y writesX() MMIO están diseñados para
2719 acceder FIFOs mapeados en memoria y basados en registros que residen en
2720 periféricos, que no son capaces de realizar DMA. Por tanto, sólo
2721 proporcionan garantías de orden readX_relaxed() y writeX_relaxed(), como
2722 se documentó anteriormente.
2726 Los puntos de entrada inX() y outX() están destinados a acceder a mapas
2727 de puertos "legacy" (antiguos) de periféricos de E/S, que pueden requerir
2728 instrucciones especiales en algunas arquitecturas (especialmente, en
2729 x86). El número de puerto del periférico que se está accedido se pasa
2732 Dado que muchas arquitecturas de CPU acceden finalmente a estos
2733 periféricos a través de un mapeo interno de memoria virtual, las
2734 garantías de orden portátiles proporcionadas por inX() y outX() son las
2735 mismas que las proporcionadas por readX() y writeX(), respectivamente, al
2736 acceder a una asignación con los valores de atributos de E/S
2737 predeterminados (los que haya por defecto).
2739 Los drivers de dispositivos pueden esperar que outX() emita una
2740 transacción de escritura no publicada, que espera una respuesta de
2741 finalización del periférico de E/S antes de regresar. Esto no está
2742 garantizado por todas las arquitecturas y por lo tanto no forma parte de
2743 la semántica de orden portátil.
2745 (*) insX(), outsX():
2747 Como arriba, los puntos de entrada insX() y outsX() proporcionan el mismo
2748 orden garantizado por readsX() y writesX() respectivamente, al acceder a
2749 un mapping con los atributos de E/S predeterminados.
2751 (*) ioreadX(), iowriteX():
2753 Estos funcionarán adecuadamente para el tipo de acceso que realmente están
2754 haciendo, ya sea inX()/outX() o readX()/writeX().
2756 Con la excepción de los puntos de entrada (insX(), outsX(), readsX() y
2757 writesX()), todo lo anterior supone que el periférico subyacente es
2758 little-endian y, por lo tanto, realizará operaciones de intercambio de
2759 bytes en arquitecturas big-endian.
2762 ===========================================
2763 MODELO DE ORDEN MÍNIMO DE EJECUCIÓN ASUMIDO
2764 ===========================================
2766 Debe suponerse que la CPU conceptual está débilmente ordenada, pero que
2767 mantiene la apariencia de causalidad del programa con respecto a sí misma.
2768 Algunas CPU (como i386 o x86_64) están más limitadas que otras (como
2769 powerpc o frv), por lo que el caso más relajado (es decir, DEC Alpha) se
2770 debe asumir fuera de código específico de arquitectura.
2772 Esto significa que se debe considerar que la CPU ejecutará su flujo de
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,
2775 entonces dicha instrucción anterior debe ser lo suficientemente completa[*]
2776 antes de que la posterior instrucción puede proceder; en otras palabras:
2777 siempre que la apariencia de causalidad se mantenga.
2779 [*] Algunas instrucciones tienen más de un efecto, como cambiar el
2780 código de condición, cambio de registros o cambio de memoria - y
2781 distintas instrucciones pueden depender de diferentes efectos.
2783 Una CPU puede también descartar cualquier secuencia de instrucciones que
2784 termine sin tener efecto final. Por ejemplo, si dos instrucciones
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
2790 corriente de instrucciones de la manera que crea conveniente, nuevamente
2791 siempre que la apariencia de causalidad se mantenga.
2794 =====================================
2795 EFECTOS DE LA MEMORIA CACHÉ DE LA CPU
2796 =====================================
2798 La forma en que se perciben las operaciones de memoria caché en todo el
2799 sistema se ve afectada, hasta cierto punto, por los cachés que se
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
2804 través del caché, el sistema de memoria tiene que incluir los cachés de la
2805 CPU y barreras de memoria, que en su mayor parte actúan en la interfaz
2806 entre la CPU y su caché (las barreras de memoria lógicamente actúan sobre
2807 la línea de puntos en el siguiente diagrama):
2809 <--- CPU ---> : <----------- Memoria ----------->
2811 +--------+ +--------+ : +--------+ +-----------+
2812 | Core | | Cola | : | Cache | | | +---------+
2813 | CPU | | de | : | CPU | | | | |
2814 | |--->| acceso |----->| |<-->| | | |
2815 | | | a | : | | | |--->| Memoria |
2816 | | | memoria| : | | | | | |
2817 +--------+ +--------+ : +--------+ | Mecanismo | | |
2818 : | de | +---------+
2820 : | de la | +--------+
2821 +--------+ +--------+ : +--------+ | cache | | |
2822 | Core | | Cola | : | Cache | | | | |
2823 | CPU | | de | : | CPU | | |--->| Dispos |
2824 | |--->| acceso |----->| |<-->| | | itivo |
2825 | | | a | : | | | | | |
2826 | | | memoria| : | | | | +--------+
2827 +--------+ +--------+ : +--------+ +-----------+
2831 Aunque es posible que una carga o store en particular no aparezca fuera de
2832 la CPU que lo emitió, ya que puede haber sido satisfecha dentro del propio
2833 caché de la CPU, seguirá pareciendo como si el acceso total a la memoria
2834 hubiera tenido lugar para las otras CPUs, ya que los mecanismos de
2835 coherencia de caché migrarán la cacheline sobre la CPU que accede y se
2836 propagarán los efectos en caso de conflicto.
2838 El núcleo de la CPU puede ejecutar instrucciones en el orden que considere
2839 adecuado, siempre que parezca mantenerse la causalidad esperada del
2840 programa. Algunas de las instrucciones generan operaciones de carga y
2841 almacenamiento que luego van a la cola de accesos a memoria a realizar. El
2842 núcleo puede colocarlos en la cola en cualquier orden que desee, y
2843 continuar su ejecución hasta que se vea obligado a esperar que una
2844 instrucción sea completada.
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
2849 que sucedan por esto.
2851 [!] Las barreras de memoria _no_ son necesarias dentro de una CPU
2852 determinada, ya que las CPU siempre ven sus propias cargas y stores como si
2853 hubieran sucedido en el orden del programa.
2855 [!] Los accesos a MMIO u otros dispositivos pueden pasar por alto el
2856 sistema de caché. Esto depende de las propiedades de la ventana de memoria
2857 a través de la cual se accede a los dispositivos y/o el uso de
2858 instrucciones especiales de comunicación con dispositivo que pueda tener la
2862 COHERENCIA DE CACHÉ FRENTE A DMA
2863 ---------------------------------
2865 No todos los sistemas mantienen coherencia de caché con respecto a los
2866 dispositivos que realizan DMA. En tales casos, un dispositivo que intente
2867 DMA puede obtener datos obsoletos de la RAM, porque las líneas de caché
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
2871 cada CPU (y tal vez también invalidarlos).
2873 Además, los datos enviados por DMA a RAM, por un dispositivo, pueden ser
2874 sobrescritos por líneas de caché sucias que se escriben de nuevo en la RAM
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
2879 y se vuelve a cargar. Para hacer frente a esto, la parte apropiada del
2880 kernel debe invalidar los bits superpuestos del caché en cada CPU.
2882 Consulte Documentation/core-api/cachetlb.rst para obtener más información
2883 sobre administración de la memoria caché.
2886 COHERENCIA DE CACHÉ FRENTE A MMIO
2887 ---------------------------------
2889 La E/S mapeada en memoria generalmente se lleva a cabo a través de
2890 ubicaciones de memoria que forman parte de una ventana del espacio de
2891 memoria de la CPU, que tiene diferentes propiedades asignadas que la
2892 ventana habitual dirigida a RAM.
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
2896 buses del dispositivo. Esto significa que los accesos MMIO pueden, en
2897 efecto, superar los accesos a la memoria caché que se emitieron
2898 anteriormente. Una barrera de memoria no es suficiente en tal caso, sino
2899 que el caché debe ser vaciado entre la escritura de la memoria caché, y el
2900 acceso MMIO, si los dos son de cualquier manera dependiente.
2903 =======================
2904 COSAS QUE HACEN LAS CPU
2905 =======================
2907 Un programador podría dar por sentado que la CPU realizará las operaciones
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:
2917 esperarían entonces que la CPU complete la operación de memoria para cada
2918 instrucción antes de pasar a la siguiente, lo que lleva a una definida
2919 secuencia de operaciones vistas por observadores externos en el sistema:
2921 LOAD *A, STORE *B, LOAD *C, LOAD *D, STORE *E.
2923 La realidad es, por supuesto, mucho más intrincada. Para muchas CPU y
2924 compiladores, la anterior suposición no se sostiene porque:
2926 (*) es más probable que las cargas deban completarse de inmediato para
2927 permitir progreso en la ejecución, mientras que los stores a menudo se
2928 pueden aplazar sin problema;
2930 (*) las cargas se pueden hacer especulativamente, y el resultado es
2931 descartado si resulta innecesario;
2933 (*) las cargas se pueden hacer de forma especulativa, lo que lleva a que
2934 se haya obtenido el resultado en el momento equivocado de la secuencia
2935 de eventos esperada;
2937 (*) el orden de los accesos a memoria se puede reorganizar para promover
2938 un mejor uso de los buses y cachés de la CPU;
2940 (*) las cargas y los stores se pueden combinar para mejorar el rendimiento
2941 cuando se habla con memoria o hardware de E/S, que puede realizar
2942 accesos por lotes a ubicaciones adyacentes, reduciendo así los costes
2943 de configuración de transacciones (la memoria y los dispositivos PCI
2944 pueden ambos pueden hacer esto); y
2946 (*) la caché de datos de la CPU puede afectar al orden, y mientras sus
2947 mecanismos de coherencia pueden aliviar esto, una vez que el store
2948 haya accedido al caché- no hay garantía de que la gestión de la
2949 coherencia se propague en orden a otras CPU.
2951 Entonces, digamos que lo que otra CPU podría observar en el fragmento de
2954 LOAD *A, ..., LOAD {*C,*D}, STORE *E, STORE *B
2956 (Donde "LOAD {*C,*D}" es una carga combinada)
2959 Sin embargo, se garantiza que una CPU es autoconsistente: verá que sus
2960 _propios_ accesos parecen estar correctamente ordenados, sin necesidad de
2961 barrera de memoria. Por ejemplo con el siguiente código:
2970 y asumiendo que no hay intervención de una influencia externa, se puede
2971 suponer que el resultado final se parecerá a:
2973 U == el valor original de *A
2978 El código anterior puede hacer que la CPU genere la secuencia completa de
2981 U=LOAD *A, STORE *A=V, STORE *A=W, X=LOAD *A, STORE *A=Y, Z=LOAD *A
2983 en ese orden, pero, sin intervención, la secuencia puede contener casi
2984 cualquier combinación de elementos combinados o descartados, siempre que la
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,
2987 ya que hay arquitecturas donde una CPU determinada podría reordenar cargas
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
2990 Itanium los casts volátiles utilizados por READ_ONCE() y WRITE_ONCE() hacen
2991 que GCC emita las instrucciones especiales ld.acq y st.rel
2992 (respectivamente) que impiden dicha reordenación.
2994 El compilador también puede combinar, descartar o diferir elementos de la
2995 secuencia antes incluso de que la CPU los vea.
3006 ya que, sin una barrera de escritura o WRITE_ONCE(), puede que se asuma
3007 que el efecto del almacenamiento de V a *A se pierde. Similarmente:
3012 puede, sin una barrera de memoria o un READ_ONCE() y WRITE_ONCE(), esto
3018 y la operación LOAD nunca aparezca fuera de la CPU.
3021 Y LUEGO ESTÁ EL ALFA
3022 --------------------
3024 La CPU DEC Alpha es una de las CPU más relajadas que existen. No solo eso,
3025 algunas versiones de la CPU Alpha tienen un caché de datos dividido, lo que
3026 les permite tener dos líneas de caché relacionadas semánticamente,
3027 actualizadas en momentos separados. Aquí es donde la barrera de dependencia
3028 de dirección realmente se vuelve necesaria, ya que se sincronizan ambos
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
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.
3038 GUESTS DE MÁQUINAS VIRTUALES
3039 -----------------------------
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
3043 compila sin compatibilidad con SMP. Este es un efecto de la interacción con
3044 un host SMP mientras ejecuta un kernel UP. El uso obligatorio de barreras
3045 para este caso de uso sería posible, pero a menudo no son óptimas.
3047 Para hacer frente a este caso de manera óptima, están disponibles macros de
3048 bajo nivel virt_mb() etc. Estas tienen el mismo efecto que smp_mb(), etc.
3049 cuando SMP está habilitado, pero generan código idéntico para sistemas SMP
3050 y no SMP. Por ejemplo, los invitados de máquinas virtuales debería usar
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
3056 efectos MMIO, utilice barreras obligatorias.
3066 Las barreras de memoria se pueden utilizar para implementar almacenamiento
3067 en búfer circular, sin necesidad de un cerrojo para serializar al productor
3068 con el consumidor. Vea:
3070 Documentation/core-api/circular-buffers.rst
3079 Alpha AXP Architecture Reference Manual, Segunda Edición (por Sites & Witek,
3081 Capítulo 5.2: Physical Address Space Characteristics
3082 Capítulo 5.4: Caches and Write Buffers
3083 Capítulo 5.5: Data Sharing
3084 Capítulo 5.6: Read/Write Ordering
3086 AMD64 Architecture Programmer's Manual Volumen 2: System Programming
3087 Capítulo 7.1: Memory-Access Ordering
3088 Capítulo 7.4: Buffering and Combining Memory Writes
3090 ARM Architecture Reference Manual (ARMv8, for ARMv8-A architecture profile)
3091 Capítulo B2: The AArch64 Application Level Memory Model
3093 IA-32 Intel Architecture Software Developer's Manual, Volumen 3:
3094 System Programming Guide
3095 Capítulo 7.1: Locked Atomic Operations
3096 Capítulo 7.2: Memory Ordering
3097 Capítulo 7.4: Serializing Instructions
3099 The SPARC Architecture Manual, Version 9
3100 Capítulo 8: Memory Models
3101 Appendix D: Formal Specification of the Memory Models
3102 Appendix J: Programming with the Memory Models
3104 Storage in the PowerPC (por Stone and Fitzgerald)
3106 UltraSPARC Programmer Reference Manual
3107 Capítulo 5: Memory Accesses and Cacheability
3108 Capítulo 15: Sparc-V9 Memory Models
3110 UltraSPARC III Cu User's Manual
3111 Capítulo 9: Memory Models
3113 UltraSPARC IIIi Processor User's Manual
3114 Capítulo 8: Memory Models
3116 UltraSPARC Architecture 2005
3118 Appendix D: Formal Specifications of the Memory Models
3120 UltraSPARC T1 Supplement to the UltraSPARC Architecture 2005
3121 Capítulo 8: Memory Models
3122 Appendix F: Caches and Cache Coherency
3124 Solaris Internals, Core Kernel Architecture, p63-68:
3125 Capítulo 3.3: Hardware Considerations for Locks and
3128 Unix Systems for Modern Architectures, Symmetric Multiprocessing and Caching
3129 for Kernel Programmers:
3130 Capítulo 13: Other Memory Models
3132 Intel Itanium Architecture Software Developer's Manual: Volumen 1:
3133 Sección 2.6: Speculation
3134 Sección 4.4: Memory Access
projects / linux-modified.git / blob