1NOTE: 2This is a version of Documentation/memory-barriers.txt translated into 3Spanish by Carlos Bilbao <carlos.bilbao.osdev@gmail.com>. If you find any 4difference between this document and the original file or a problem with 5the translation, please contact the maintainer of this file. Please also 6note 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 8comments or updates for this file please update the original English file 9first. The English version is definitive, and readers should look there if 10they have any doubt. 11 12 ====================================== 13 BARRERAS DE MEMORIA EN EL KERNEL LINUX 14 ====================================== 15 16Documento 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> 20 21Traducido por: Carlos Bilbao <carlos.bilbao.osdev@gmail.com> 22Nota: Si tiene alguna duda sobre la exactitud del contenido de esta 23traducción, la única referencia válida es la documentación oficial en 24inglés. 25 26=========== 27ADVERTENCIA 28=========== 29 30Este documento no es una especificación; es intencionalmente (por motivos 31de brevedad) y sin querer (por ser humanos) incompleta. Este documento 32pretende ser una guía para usar las diversas barreras de memoria 33proporcionadas por Linux, pero ante cualquier duda (y hay muchas) por favor 34pregunte. Algunas dudas pueden ser resueltas refiriéndose al modelo de 35consistencia de memoria formal y documentación en tools/memory-model/. Sin 36embargo, incluso este modelo debe ser visto como la opinión colectiva de 37sus maintainers en lugar de que como un oráculo infalible. 38 39De nuevo, este documento no es una especificación de lo que Linux espera 40del hardware. 41 42El propósito de este documento es doble: 43 44 (1) especificar la funcionalidad mínima en la que se puede confiar para 45 cualquier barrera en concreto, y 46 47 (2) proporcionar una guía sobre cómo utilizar las barreras disponibles. 48 49Tenga en cuenta que una arquitectura puede proporcionar más que el 50requisito mínimo para cualquier barrera en particular, pero si la 51arquitectura proporciona menos de eso, dicha arquitectura es incorrecta. 52 53Tenga en cuenta también que es posible que una barrera no valga (sea no-op) 54para alguna arquitectura porque por la forma en que funcione dicha 55arquitectura, la barrera explícita resulte innecesaria en ese caso. 56 57========== 58CONTENIDOS 59========== 60 61 (*) Modelo abstracto de acceso a memoria. 62 63 - Operaciones del dispositivo. 64 - Garantías. 65 66 (*) ¿Qué son las barreras de memoria? 67 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. 76 77 (*) Barreras explícitas del kernel. 78 79 - Barrera del compilador. 80 - Barreras de memoria de la CPU. 81 82 (*) Barreras de memoria implícitas del kernel. 83 84 - Funciones de adquisición de cerrojo. 85 - Funciones de desactivación de interrupciones. 86 - Funciones de dormir y despertar. 87 - Funciones varias. 88 89 (*) Efectos de barrera adquiriendo intra-CPU. 90 91 - Adquisición vs accesos a memoria. 92 93 (*) ¿Dónde se necesitan barreras de memoria? 94 95 - Interacción entre procesadores. 96 - Operaciones atómicas. 97 - Acceso a dispositivos. 98 - Interrupciones. 99 100 (*) Efectos de barrera de E/S del kernel. 101 102 (*) Modelo de orden mínimo de ejecución asumido. 103 104 (*) Efectos de la memoria caché de la CPU. 105 106 - Coherencia de caché. 107 - Coherencia de caché frente a DMA. 108 - Coherencia de caché frente a MMIO. 109 110 (*) Cosas que hacen las CPU. 111 112 - Y luego está el Alfa. 113 - Guests de máquinas virtuales. 114 115 (*) Ejemplos de usos. 116 117 - Buffers circulares. 118 119 (*) Referencias. 120 121 122==================================== 123MODELO ABSTRACTO DE ACCESO A MEMORIA 124==================================== 125 126Considere el siguiente modelo abstracto del sistema: 127 128 : : 129 : : 130 : : 131 +-------+ : +--------+ : +-------+ 132 | | : | | : | | 133 | | : | | : | | 134 | CPU 1 |<----->| Memoria|<----->| CPU 2 | 135 | | : | | : | | 136 | | : | | : | | 137 +-------+ : +--------+ : +-------+ 138 ^ : ^ : ^ 139 | : | : | 140 | : | : | 141 | : v : | 142 | : +--------+ : | 143 | : | | : | 144 | : | Disposi| : | 145 +---------->| tivo |<----------+ 146 : | | : 147 : | | : 148 : +--------+ : 149 : : 150 151Cada CPU ejecuta un programa que genera operaciones de acceso a la memoria. 152En la CPU abstracta, el orden de las operaciones de memoria es muy 153relajado, y una CPU en realidad puede realizar las operaciones de memoria 154en el orden que desee, siempre que la causalidad del programa parezca 155mantenerse. De manera similar, el compilador también puede organizar las 156instrucciones que emite en el orden que quiera, siempre que no afecte al 157funcionamiento aparente del programa. 158 159Entonces, en el diagrama anterior, los efectos de las operaciones de 160memoria realizadas por un CPU son percibidos por el resto del sistema a 161medida que las operaciones cruzan la interfaz entre la CPU y el resto del 162sistema (las líneas discontinuas a puntos). 163 164Por ejemplo, considere la siguiente secuencia de eventos: 165 166 CPU 1 CPU 2 167 =============== =============== 168 { A == 1; B == 2 } 169 A = 3; x = B; 170 B = 4; y = A; 171 172El conjunto de accesos visto por el sistema de memoria en el medio se puede 173organizar en 24 combinaciones diferentes (donde LOAD es cargar y STORE es 174guardar): 175 176STORE A=3, STORE B=4, y=LOAD A->3, x=LOAD B->4 177STORE A=3, STORE B=4, x=LOAD B->4, y=LOAD A->3 178STORE A=3, y=LOAD A->3, STORE B=4, x=LOAD B->4 179STORE A=3, y=LOAD A->3, x=LOAD B->2, STORE B=4 180STORE A=3, x=LOAD B->2, STORE B=4, y=LOAD A->3 181STORE A=3, x=LOAD B->2, y=LOAD A->3, STORE B=4 182STORE B=4, STORE A=3, y=LOAD A->3, x=LOAD B->4 183STORE B=4, ... 184... 185 186y por lo tanto puede resultar en cuatro combinaciones diferentes de 187valores: 188 189x == 2, y == 1 190x == 2, y == 3 191x == 4, y == 1 192x == 4, y == 3 193 194Además, los stores asignados por una CPU al sistema de memoria pueden no 195ser percibidos por los loads realizados por otra CPU en el mismo orden en 196que fueron realizados. 197 198Como otro ejemplo, considere esta secuencia de eventos: 199 200 CPU 1 CPU 2 201 =============== =============== 202 { A == 1, B == 2, C == 3, P == &A, Q == &C } 203 B = 4; Q = P; 204 P = &B; D = *Q; 205 206Aquí hay una dependencia obvia de la dirección, ya que el valor cargado en 207D depende en la dirección recuperada de P por la CPU 2. Al final de la 208secuencia, cualquiera de los siguientes resultados son posibles: 209 210 (Q == &A) y (D == 1) 211 (Q == &B) y (D == 2) 212 (Q == &B) y (D == 4) 213 214Tenga en cuenta que la CPU 2 nunca intentará cargar C en D porque la CPU 215cargará P en Q antes de emitir la carga de *Q. 216 217OPERACIONES DEL DISPOSITIVO 218--------------------------- 219 220Algunos dispositivos presentan sus interfaces de control como colecciones 221de ubicaciones de memoria, pero el orden en que se accede a los registros 222de control es muy importante. Por ejemplo, imagine una tarjeta ethernet con 223un conjunto de registros a los que se accede a través de un registro de 224puerto de dirección (A) y un registro de datos del puerto (D). Para leer el 225registro interno 5, el siguiente código podría entonces ser usado: 226 227 *A = 5; 228 x = *D; 229 230pero esto podría aparecer como cualquiera de las siguientes dos secuencias: 231 232 STORE *A = 5, x = LOAD *D 233 x = LOAD *D, STORE *A = 5 234 235el segundo de las cuales casi con certeza resultará en mal funcionamiento, 236ya que se estableció la dirección _después_ de intentar leer el registro. 237 238 239GARANTÍAS 240--------- 241 242Hay algunas garantías mínimas que se pueden esperar de una CPU: 243 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: 246 247 Q = READ_ONCE(P); D = READ_ONCE(*Q); 248 249 donde READ_ONCE() es LEER_UNA_VEZ(), la CPU emitirá las siguientes 250 operaciones de memoria: 251 252 Q = LOAD P, D = LOAD *Q 253 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: 257 258 Q = LOAD P, MEMORY_BARRIER, D = LOAD *Q, MEMORY_BARRIER 259 260 Ya sea en DEC Alpha o no, READ_ONCE() también evita que el compilador 261 haga cosas inapropiadas. 262 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: 265 266 a = READ_ONCE(*X); WRITE_ONCE(*X, b); 267 268 donde WRITE_ONCE() es ESCRIBIR_UNA_VEZ(), la CPU solo emitirá la 269 siguiente secuencia de operaciones de memoria: 270 271 a = LOAD *X, STORE *X = b 272 273 Y para: 274 275 WRITE_ONCE(*X, c); d = READ_ONCE(*X); 276 277 la CPU solo emitirá: 278 279 STORE *X = c, d = LOAD *X 280 281 (Los loads y stores se superponen si están destinados a piezas 282 superpuestas de memoria). 283 284Y hay una serie de cosas que _deben_ o _no_ deben asumirse: 285 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 290 DEL COMPILADOR. 291 292 (*) _No_debe_ suponerse que se emitirán loads y stores independientes 293 en el orden dado. Esto significa que para: 294 295 X = *A; Y = *B; *D = Z; 296 297 podemos obtener cualquiera de las siguientes secuencias: 298 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 305 306 (*) Se _debe_ suponer que los accesos de memoria superpuestos pueden 307 fusionarse o ser descartados. Esto significa que para: 308 309 X = *A; Y = *(A + 4); 310 311 podemos obtener cualquiera de las siguientes secuencias: 312 313X = LOAD *A; Y = LOAD *(A + 4); 314Y = LOAD *(A + 4); X = LOAD *A; 315{X, Y} = LOAD {*A, *(A + 4) }; 316 317 Y para: 318 319*A = X; *(A + 4) = Y; 320 321 podemos obtener cualquiera de: 322 323STORE *A = X; STORE *(A + 4) = Y; 324STORE *(A + 4) = Y; STORE *A = X; 325STORE {*A, *(A + 4) } = {X, Y}; 326 327Y hay anti-garantías: 328 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. 333 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 340 un campo adyacente. 341 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 353 manera: 354 355 ubicación de memoria 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 358 359 NOTE 1: Dos hilos de ejecución pueden actualizar y acceder 360 ubicaciones de memoria separadas sin interferir entre 361 ellos. 362 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. 372 373 374================================== 375¿QUÉ SON LAS BARRERAS DE MEMORIA? 376================================== 377 378Como se puede leer arriba, las operaciones independientes de memoria se 379realizan de manera efectiva en orden aleatorio, pero esto puede ser un 380problema para la interacción CPU-CPU y para la E/S ("I/O"). Lo que se 381requiere es alguna forma de intervenir para instruir al compilador y al 382CPU para restringir el orden. 383 384Las barreras de memoria son este tipo de intervenciones. Imponen una 385percepción de orden parcial, sobre las operaciones de memoria a ambos lados 386de la barrera. 387 388Tal cumplimiento es importante porque las CPUs y otros dispositivos en un 389sistema pueden usar una variedad de trucos para mejorar el rendimiento, 390incluido el reordenamiento, diferimiento y combinación de operaciones de 391memoria; cargas especulativas; predicción de "branches" especulativos y 392varios tipos de almacenamiento en caché. Las barreras de memoria se 393utilizan para anular o suprimir estos trucos, permitiendo que el código 394controle sensatamente la interacción de múltiples CPU y/o dispositivos. 395 396 397VARIEDADES DE BARRERA DE MEMORIA 398--------------------------------- 399 400Las barreras de memoria vienen en cuatro variedades básicas: 401 402 (1) Barreras de memoria al escribir o almacenar (Write or store memory 403 barriers). 404 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. 409 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. 412 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. 417 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". 422 423 424 (2) Barrera de dependencia de dirección (histórico). 425 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. 433 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. 438 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. 447 448 Consulte la subsección "Ejemplos de secuencias de barrera de memoria" 449 para ver los diagramas mostrando las restricciones de orden. 450 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. 458 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". 462 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. 467 468 (3) Barreras de memoria al leer o cargar (Read or load memory 469 barriers). 470 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. 476 477 Una barrera de lectura es un orden parcial solo en cargas; no es 478 necesario que tenga ningún efecto en los stores. 479 480 Las barreras de memoria de lectura implican barreras de dependencia de 481 direcciones, y por tanto puede sustituirlas por estas. 482 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". 486 487 (4) Barreras de memoria generales 488 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. 494 495 Una barrera de memoria general es un orden parcial tanto en 496 operaciones de carga como de almacenamiento. 497 498 Las barreras de memoria generales implican barreras de memoria tanto 499 de lectura como de escritura, de modo que pueden sustituir a 500 cualquiera. 501 502Y un par de variedades implícitas: 503 504 (5) ACQUIRE (de adquisición). 505 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(). 511 512 Las operaciones de memoria que ocurren antes de una operación ACQUIRE 513 pueden parecer suceder después de que se complete. 514 515 Una operación ACQUIRE casi siempre debe estar emparejada con una 516 operación RELEASE (de liberación). 517 518 519 (6) Operaciones RELEASE (de liberación). 520 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(). 526 527 Las operaciones de memoria que ocurren después de una operación 528 RELEASE pueden parecer suceder antes de que se complete. 529 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. 539 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 542 "liberación". 543 544Un subconjunto de las operaciones atómicas descritas en atomic_t.txt 545contiene variantes de ACQUIRE y RELEASE, además de definiciones 546completamente ordenadas o relajadas (sin barrera semántica). Para 547composiciones atómicas que realizan tanto un load como store, la semántica 548ACQUIRE se aplica solo a la carga y la semántica RELEASE se aplica sólo a 549la parte de la operación del store. 550 551Las barreras de memoria solo son necesarias cuando existe la posibilidad de 552interacción entre dos CPU o entre una CPU y un dispositivo. Si se puede 553garantizar que no habrá tal interacción en ninguna pieza de código en 554particular, entonces las barreras de memoria son innecesarias en ese 555fragmento de código. 556 557Tenga en cuenta que estas son las garantías _mínimas_. Diferentes 558arquitecturas pueden proporcionar garantías más sustanciales, pero no se 559puede confiar en estas fuera de esa arquitectura en específico. 560 561 562¿QUÉ NO SE PUEDE ASUMIR SOBRE LAS BARRERAS DE LA MEMORIA? 563--------------------------------------------------------- 564 565Hay ciertas cosas que las barreras de memoria del kernel Linux no 566garantizan: 567 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. 573 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: 579 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 584 barrera SMP"). 585 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 590 en orden. 591 592 [*] Para obtener información sobre bus mastering DMA y coherencia, lea: 593 594 Documentation/driver-api/pci/pci.rst 595 Documentation/core-api/dma-api-howto.rst 596 Documentation/core-api/dma-api.rst 597 598 599BARRERA DE DEPENDENCIA DE DIRECCIÓN (HISTÓRICO) 600----------------------------------------------- 601 602A partir de la versión 4.15 del kernel Linux, se agregó un smp_mb() a 603READ_ONCE() para DEC Alpha, lo que significa que las únicas personas que 604necesitan prestar atención a esta sección son aquellas que trabajan en el 605código específico de la arquitectura DEC Alpha y aquellas que trabajan en 606READ_ONCE() por dentro. Para aquellos que lo necesitan, y para aquellos que 607estén interesados desde un punto de vista histórico, aquí está la historia 608de las barreras de dependencia de dirección. 609 610[!] Si bien las dependencias de direcciones se observan tanto en carga a 611carga como en relaciones de carga a store, las barreras de dependencia de 612dirección no son necesarias para situaciones de carga a store. 613 614El requisito de las barreras de dependencia de dirección es un poco sutil, 615y no siempre es obvio que sean necesarias. Para ilustrar, considere la 616siguiente secuencia de eventos: 617 618 CPU 1 CPU 2 619 =============== =============== 620 { A == 1, B == 2, C == 3, P == &A, Q == &C } 621 B = 4; 622 <barrera de escritura> 623 WRITE_ONCE(P, &B); 624 Q = READ_ONCE_OLD(P); 625 D = *Q; 626 627[!] READ_ONCE_OLD() corresponde a READ_ONCE() del kernel anterior a 4.15, 628que no implica una barrera de dependencia de direcciones. 629 630Hay una clara dependencia de dirección aquí, y parecería que al final de 631la secuencia, Q debe ser &A o &B, y que: 632 633 (Q == &A) implica (D == 1) 634 (Q == &B) implica (D == 4) 635 636¡Pero! La percepción de la CPU 2 de P puede actualizarse _antes_ de su 637percepción de B, por lo tanto dando lugar a la siguiente situación: 638 639 (Q == &B) y (D == 2) ???? 640 641Si bien esto puede parecer una falla en el mantenimiento de la coherencia 642o la causalidad, no lo es, y este comportamiento se puede observar en 643ciertas CPU reales (como DEC Alfa). 644 645Para lidiar con esto, READ_ONCE() proporciona una barrera de dependencia 646de dirección implícita desde el lanzamiento del kernel v4.15: 647 648 CPU 1 CPU 2 649 =============== =============== 650 { A == 1, B == 2, C == 3, P == &A, Q == &C } 651 B = 4; 652 <barrera de escritura> 653 WRITE_ONCE(P, &B); 654 Q = READ_ONCE(P); 655 <barrera de dependencia de dirección implícita> 656 D = *Q; 657 658Esto refuerza la ocurrencia de una de las dos implicaciones, y previene la 659tercera posibilidad de surgir. 660 661 662[!] Tenga en cuenta que esta situación extremadamente contraria a la 663intuición surge más fácilmente en máquinas con cachés divididos, de modo 664que, por ejemplo, un banco de caché procesa líneas de caché pares y el otro 665banco procesa líneas impares de caché. El puntero P podría almacenarse en 666una línea de caché impar y la variable B podría almacenarse en una línea de 667caché con número par. Entonces, si el banco de números pares de la memoria 668caché de la CPU de lectura está extremadamente ocupado mientras que el 669banco impar está inactivo, uno podría ver el nuevo valor del puntero P 670(&B), pero el antiguo valor de la variable B (2). 671 672 673No se requiere una barrera de dependencia de dirección para ordenar 674escrituras dependientes porque las CPU que admite el kernel Linux no 675escriben hasta que están seguros (1) de que la escritura realmente 676sucederá, (2) de la ubicación de la escritura, y (3) del valor a escribir. 677Pero, por favor, lea atentamente la sección "DEPENDENCIAS DEL CONTROL" y el 678archivo Documentation/RCU/rcu_dereference.rst: el compilador puede romperse 679y romper dependencias en muchas formas altamente creativas. 680 681 CPU 1 CPU 2 682 =============== =============== 683 { A == 1, B == 2, C = 3, P == &A, Q == &C } 684 B = 4; 685 <barrera de escritura> 686 WRITE_ONCE(P, &B); 687 Q = READ_ONCE_OLD(P); 688 WRITE_ONCE(*Q, 5); 689 690Por lo tanto, no se requiere ninguna barrera de dependencia de direcciones 691para ordenar la lectura en Q con el load en *Q. En otras palabras, este 692resultado está prohibido, incluso sin una barrera de dependencia de 693dirección implícita del READ_ONCE() moderno: 694 695 (Q == &B) && (B == 4) 696 697Tenga en cuenta que este patrón debe ser raro. Después de todo, el objetivo 698del orden de dependencia es -prevenir- escrituras en la estructura de 699datos, junto con los costosos errores de caché asociados con tales 700escrituras. Este patrón se puede utilizar para registrar raras condiciones 701de error y similares, y el orden natural de las CPUs evita que se pierdan 702tales registros. 703 704 705Tenga en cuenta que el orden proporcionado por una dependencia de dirección 706es local para la CPU que lo contiene. Lea la sección sobre "Atomicidad 707multicopia" para más información. 708 709 710La barrera de dependencia de dirección es muy importante para el sistema 711RCU, por ejemplo. Vea rcu_assign_pointer() y rcu_dereference() en 712include/linux/rcupdate.h. Esto permite que el objetivo actual de un puntero 713RCU sea reemplazado con un nuevo objetivo modificado, sin que el objetivo 714del reemplazo parezca estar inicializado de manera incompleta. 715 716Consulte también la subsección sobre "Coherencia de caché" para obtener un 717ejemplo más completo. 718 719DEPENDENCIAS DE CONTROL 720----------------------- 721 722Las dependencias de control pueden ser un poco complicadas porque los 723compiladores actuales no las entienden. El propósito de esta sección es 724ayudarle a prevenir que la ignorancia del compilador rompa su código. 725 726Una dependencia de control load-load (de carga a carga) requiere una 727barrera de memoria de lectura completa, no simplemente una barrera 728(implícita) de dependencia de direcciones para que funcione correctamente. 729Considere el siguiente fragmento de código: 730 731 q = READ_ONCE(a); 732 <barrera implícita de dependencia de direcciones> 733 if (q) { 734 /* BUG: No hay dependencia de dirección!!! */ 735 p = READ_ONCE(b); 736 } 737 738Esto no tendrá el efecto deseado porque no hay una dependencia de dirección 739real, sino más bien una dependencia de control que la CPU puede 740cortocircuitar al intentar predecir el resultado por adelantado, para que 741otras CPU vean la carga de b como si hubiera ocurrido antes que la carga de 742a. En cuyo caso lo que realmente se requiere es: 743 744 q = READ_ONCE(a); 745 if (q) { 746 <barrera de lectura> 747 p = READ_ONCE(b); 748 } 749 750Sin embargo, los stores no se especulan. Esto significa que ordenar -es- 751provisto para dependencias de control de load-store, como en el siguiente 752ejemplo: 753 754 q = READ_ONCE(a); 755 if (q) { 756 WRITE_ONCE(b, 1); 757 } 758 759Las dependencias de control se emparejan normalmente con otros tipos de 760barreras. Dicho esto, tenga en cuenta que ni READ_ONCE() ni WRITE_ONCE() 761son 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 763combinar el store de 'b' con otros stores de 'b'. Cualquiera de estos casos 764puede dar lugar a efectos en el orden muy contrarios a la intuición. 765 766Peor aún, si el compilador puede probar (decir) que el valor de la 767variable 'a' siempre es distinta de cero, estaría dentro de sus derechos 768para optimizar el ejemplo original eliminando la declaración "if", como: 769 770 q = a; 771 b = 1; /* BUG: Compilador y CPU pueden ambos reordernar!!! */ 772 773Así que no deje de lado READ_ONCE(). 774 775Es tentador tratar de hacer cumplir el orden en stores idénticos en ambos 776caminos del "if" de la siguiente manera: 777 778 q = READ_ONCE(a); 779 if (q) { 780 barrier(); 781 WRITE_ONCE(b, 1); 782 hacer_algo(); 783 } else { 784 barrier(); 785 WRITE_ONCE(b, 1); 786 hacer_otra_cosa(); 787 } 788 789Desafortunadamente, los compiladores actuales transformarán esto de la 790siguiente manera en casos de alto nivel de optimización: 791 792 q = READ_ONCE(a); 793 barrier(); 794 WRITE_ONCE(b, 1); /* BUG: No hay orden en load de a!!! */ 795 if (q) { 796 /* WRITE_ONCE(b, 1); -- movido arriba, BUG!!! */ 797 hacer_algo(); 798 } else { 799 /* WRITE_ONCE(b, 1); -- movido arriba, BUG!!! */ 800 hacer_otra_cosa(); 801 } 802 803Ahora no hay condicional entre la carga de 'a' y el store de 'b', lo que 804significa que la CPU está en su derecho de reordenarlos: El condicional es 805absolutamente necesario y debe estar presente en el código ensamblador 806incluso después de que se hayan aplicado todas las optimizaciones del 807compilador. Por lo tanto, si necesita ordenar en este ejemplo, necesita 808explícitamente barreras de memoria, por ejemplo, smp_store_release(): 809 810 811 q = READ_ONCE(a); 812 if (q) { 813 smp_store_release(&b, 1); 814 hacer_algo(); 815 } else { 816 smp_store_release(&b, 1); 817 hacer_otra_cosa(); 818 } 819 820Por el contrario, sin barreras de memoria explícita, el control de un if 821con dos opciones está garantizado solo cuando los stores difieren, por 822ejemplo: 823 824 q = READ_ONCE(a); 825 if (q) { 826 WRITE_ONCE(b, 1); 827 hacer_algo(); 828 } else { 829 WRITE_ONCE(b, 2); 830 hacer_otra_cosa(); 831 } 832 833Aún se requiere el inicial READ_ONCE() para evitar que el compilador toque 834el valor de 'a'. 835 836Además, debe tener cuidado con lo que hace con la variable local 'q', de lo 837contrario, el compilador podría adivinar el valor y volver a eliminar el 838necesario condicional. Por ejemplo: 839 840 q = READ_ONCE(a); 841 if (q % MAX) { 842 WRITE_ONCE(b, 1); 843 hacer_algo(); 844 } else { 845 WRITE_ONCE(b, 2); 846 hacer_otra_cosa(); 847 } 848 849Si MAX se define como 1, entonces el compilador sabe que (q % MAX) es igual 850a cero, en cuyo caso el compilador tiene derecho a transformar el código 851anterior en el siguiente: 852 853 q = READ_ONCE(a); 854 WRITE_ONCE(b, 2); 855 hacer_otra_cosa(); 856 857Dada esta transformación, la CPU no está obligada a respetar el orden entre 858la carga de la variable 'a' y el store de la variable 'b'. Es tentador 859agregar una barrier(), pero esto no ayuda. El condicional se ha ido, y la 860barrera no lo traerá de vuelta. Por lo tanto, si confia en este orden, debe 861asegurarse de que MAX sea mayor que uno, tal vez de la siguiente manera: 862 863 q = READ_ONCE(a); 864 BUILD_BUG_ON(MAX <= 1); /* Orden de carga de a con store de b */ 865 if (q % MAX) { 866 WRITE_ONCE(b, 1); 867 hacer_algo(); 868 } else { 869 WRITE_ONCE(b, 2); 870 hacer_otra_cosa(); 871 } 872 873Tenga en cuenta una vez más que los stores de 'b' difieren. Si fueran 874idénticos, como se señaló anteriormente, el compilador podría sacar ese 875store fuera de la declaración 'if'. 876 877También debe tener cuidado de no confiar demasiado en el cortocircuito 878de la evaluación booleana. Considere este ejemplo: 879 880 q = READ_ONCE(a); 881 if (q || 1 > 0) 882 WRITE_ONCE(b, 1); 883 884Debido a que la primera condición no puede fallar y la segunda condición es 885siempre cierta, el compilador puede transformar este ejemplo de la 886siguiente manera, rompiendo la dependencia del control: 887 888 q = READ_ONCE(a); 889 WRITE_ONCE(b, 1); 890 891Este ejemplo subraya la necesidad de asegurarse de que el compilador no 892pueda adivinar su código. Más generalmente, aunque READ_ONCE() fuerza 893al compilador para emitir código para una carga dada, no fuerza al 894compilador para usar los resultados. 895 896Además, las dependencias de control se aplican solo a la cláusula then y 897la cláusula else de la sentencia if en cuestión. En particular, no se 898aplica necesariamente al código que sigue a la declaración if: 899 900 q = READ_ONCE(a); 901 if (q) { 902 WRITE_ONCE(b, 1); 903 } else { 904 WRITE_ONCE(b, 2); 905 } 906 WRITE_ONCE(c, 1); /* BUG: No hay orden para la lectura de 'a'. */ 907 908Es tentador argumentar que, de hecho, existe un orden porque el compilador 909no puede reordenar accesos volátiles y tampoco puede reordenar escrituras 910en 'b' con la condición. Desafortunadamente para esta línea de 911razonamiento, el compilador podría compilar las dos escrituras en 'b' como 912instrucciones de movimiento condicional, como en este fantástico idioma 913pseudo-ensamblador: 914 915 ld r1,a 916 cmp r1,$0 917 cmov,ne r4,$1 918 cmov,eq r4,$2 919 st r4,b 920 st $1,c 921 922Una CPU débilmente ordenada no tendría dependencia de ningún tipo entre la 923carga de 'a' y el store de 'c'. Las dependencias de control se extenderían 924solo al par de instrucciones cmov y el store dependiente de ellas. En 925resumen, las dependencias de control se aplican solo a los stores en la 926cláusula then y la cláusula else de la sentencia if en cuestión (incluidas 927las funciones invocado por esas dos cláusulas), no al código que sigue a 928esa declaración if. 929 930 931Tenga muy en cuenta que el orden proporcionado por una dependencia de 932control es local a la CPU que lo contiene. Vea el apartado de "Atomicidad 933multicopia" para más información. 934 935 936En resumen: 937 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(). 944 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(). 953 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. 960 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. 966 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. 972 973 (*) Las dependencias de control se emparejan normalmente con otros tipos 974 de barreras. 975 976 (*) Las dependencias de control no proporcionan atomicidad multicopia. Si 977 usted necesita todas las CPU para ver un store dado al mismo tiempo, 978 emplee smp_mb(). 979 980 (*) Los compiladores no entienden las dependencias de control. Por lo 981 tanto es su trabajo asegurarse de que no rompan su código. 982 983 984EMPAREJAMIENTO DE BARRERAS SMP 985------------------------------ 986 987Cuando se trata de interacciones CPU-CPU, ciertos tipos de barrera de 988memoria deben estar siempre emparejados. La falta del apropiado 989emparejamiento es casi seguro un error. 990 991Las barreras generales se emparejan entre sí, aunque también se emparejan 992con la mayoría de otro tipo de barreras, aunque sin atomicidad multicopia. 993Una barrera de adquisición se empareja con una barrera de liberación, pero 994ambas también pueden emparejarse con otras barreras, incluidas, por 995supuesto, las barreras generales. Una barrera de escritura se empareja con 996una barrera de dependencia de dirección, una dependencia de control, una 997barrera de adquisición, una barrera de liberación, una barrera de lectura 998o una barrera general. Del mismo modo, una barrera de lectura se empareja 999con una de dependencia de control o barrera de dependencia de dirección con 1000una barrera de escritura, una barrera de adquisición, una barrera de 1001liberación o una barrera general: 1002 1003 CPU 1 CPU 2 1004 =============== =============== 1005 WRITE_ONCE(a, 1); 1006 <barrera de escritura> 1007 WRITE_ONCE(b, 2); x = READ_ONCE(b); 1008 <barrera de lectura> 1009 y = READ_ONCE(a); 1010 1011O bien: 1012 1013 CPU 1 CPU 2 1014 =============== =============================== 1015 a = 1; 1016 <barrera de escritura> 1017 WRITE_ONCE(b, &a); x = READ_ONCE(b); 1018 <barrera de dependencia de dirección implícita> 1019 y = *x; 1020 1021O incluso: 1022 1023 CPU 1 CPU 2 1024 =============== =============================== 1025 r1 = READ_ONCE(y); 1026 <barrera general> 1027 WRITE_ONCE(x, 1); if (r2 = READ_ONCE(x)) { 1028 <barrera de control implícita> 1029 WRITE_ONCE(y, 1); 1030 } 1031 1032 assert(r1 == 0 || r2 == 0); 1033 1034Básicamente, la barrera de lectura siempre tiene que estar ahí, aunque 1035puede ser del tipo "más débil". 1036 1037[!] Tenga en cuenta que normalmente se esperaría que los stores antes de la 1038barrera de escritura se hagan coincidir con los stores después de la 1039barrera de lectura o la barrera de dependencia de dirección, y viceversa: 1040 1041 CPU 1 CPU 2 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); 1048 1049 1050EJEMPLOS DE SECUENCIAS DE BARRERA DE MEMORIA 1051-------------------------------------------- 1052 1053En primer lugar, las barreras de escritura actúan como orden parcial en las 1054operaciones de store. Considere la siguiente secuencia de eventos: 1055 1056 CPU 1 1057 ======================= 1058 STORE A = 1 1059 STORE B = 2 1060 STORE C = 3 1061 <barrera de escritura> 1062 STORE D = 4 1063 STORE E = 5 1064 1065Esta secuencia de eventos es finalizado para con el sistema de coherencia 1066de memoria en un orden que el resto del sistema podría percibir como el 1067conjunto desordenado { STORE A, STORE B, STORE C} todo ocurriendo antes del 1068conjunto desordenado { STORE D, STORE E}: 1069 1070 1071 +-------+ : : 1072 | | +------+ 1073 | |------>| C=3 | } /\ 1074 | | : +------+ }----- \ -----> Eventos perceptibles para 1075 | | : | A=1 | } \/ el resto del sistema 1076 | | : +------+ } 1077 | CPU 1 | : | B=2 | } 1078 | | +------+ } 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 1084 | | +------+ 1085 +-------+ : : 1086 | 1087 | Secuencia por la cual los stores son confirmados al 1088 | sistema de memoria por parte del CPU 1 1089 V 1090 1091En segundo lugar, las barreras de dependencia de dirección actúan como 1092órdenes parciales sobre la dirección de cargas dependientes. Considere la 1093siguiente secuencia de eventos: 1094 1095 CPU 1 CPU 2 1096 ======================= ======================= 1097 { B = 7; X = 9; Y = 8; C = &Y } 1098 STORE A = 1 1099 STORE B = 2 1100 <barrera de escritura> 1101 STORE C = &B LOAD X 1102 STORE D = 4 LOAD C (consigue &B) 1103 LOAD *C (lee B) 1104 1105Sin intervención, la CPU 2 puede percibir los eventos en la CPU 1 en orden 1106aleatorio a efectos prácticos, a pesar de la barrera de escritura emitida 1107por la CPU 1: 1108 1109 +-------+ : : : : 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 | : : 1116 | | +------+ | : : 1117 | | : | C=&B |--- | : : +-------+ 1118 | | : +------+ \ | +-------+ | | 1119 | |------>| D=4 | ----------->| C->&B |------>| | 1120 | | +------+ | +-------+ | | 1121 +-------+ : : | : : | | 1122 | : : | | 1123 | : : | CPU 2 | 1124 | +-------+ | | 1125 Percepción de B ---> | | B->7 |------>| | 1126 aparentemente incorrecta! | +-------+ | | 1127 | : : | | 1128 | +-------+ | | 1129 La carga de X frena ---> \ | X->9 |------>| | 1130 el mantenimiento de \ +-------+ | | 1131 la coherencia de B ----->| B->2 | +-------+ 1132 +-------+ 1133 : : 1134 1135 1136En 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. 1138 1139Sin embargo, si se colocara una barrera de dependencia de dirección entre 1140la carga de C y la carga de *C (es decir: B) en la CPU 2: 1141 1142 CPU 1 CPU 2 1143 ======================= ======================= 1144 { B = 7; X = 9; Y = 8; C = &Y } 1145 STORE A = 1 1146 STORE B = 2 1147 <barrera de escritura> 1148 STORE C = &B LOAD X 1149 STORE D = 4 LOAD C (consigue &B) 1150 <barrera de dependencia de dirección> 1151 LOAD *C (reads B) 1152 1153entonces ocurrirá lo siguiente: 1154 1155 +-------+ : : : : 1156 | | +------+ +-------+ 1157 | |------>| B=2 |----- --->| Y->8 | 1158 | | : +------+ \ +-------+ 1159 | CPU 1 | : | A=1 | \ --->| C->&Y | 1160 | | +------+ | +-------+ 1161 | | wwwwwwwwwwwwwwww | : : 1162 | | +------+ | : : 1163 | | : | C=&B |--- | : : +-------+ 1164 | | : +------+ \ | +-------+ | | 1165 | |------>| D=4 | ----------->| C->&B |------>| | 1166 | | +------+ | +-------+ | | 1167 +-------+ : : | : : | | 1168 | : : | | 1169 | : : | CPU 2 | 1170 | +-------+ | | 1171 | | X->9 |------>| | 1172 | +-------+ | | 1173 Se asegura de que ---> \ aaaaaaaaaaaaaaaaa | | 1174 los efectos anteriores al \ +-------+ | | 1175 store de C sean percibidos ----->| B->2 |------>| | 1176 por los siguientes loads +-------+ | | 1177 : : +-------+ 1178 1179 1180Y en tercer lugar, una barrera de lectura actúa como un orden parcial sobre 1181las cargas. Considere la siguiente secuencia de eventos: 1182 1183 CPU 1 CPU 2 1184 ======================= ======================= 1185 { A = 0, B = 9 } 1186 STORE A=1 1187 <barrera de escritura> 1188 STORE B=2 1189 LOAD B 1190 LOAD A 1191 1192Sin intervención, la CPU 2 puede elegir percibir los eventos en la CPU 1 en 1193algún orden aleatorio a efectos prácticos, a pesar de la barrera de 1194escritura emitida por la CPU 1: 1195 1196 +-------+ : : : : 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 |------>| | 1208 | +-------+ | | 1209 | : : +-------+ 1210 \ : : 1211 \ +-------+ 1212 ---->| A->1 | 1213 +-------+ 1214 : : 1215 1216Sin embargo, si se colocara una barrera de lectura entre la carga de B y la 1217carga de A en la CPU 2: 1218 1219 CPU 1 CPU 2 1220 ======================= ======================= 1221 { A = 0, B = 9 } 1222 STORE A=1 1223 <barrera de escritura> 1224 STORE B=2 1225 LOAD B 1226 <barrera de lectura> 1227 LOAD A 1228 1229entonces el orden parcial impuesto por la CPU 1 será percibido 1230correctamente por la CPU 2: 1231 1232 +-------+ : : : : 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 | 1243 | : : | | 1244 | : : | | 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 : : +-------+ 1250 1251 1252Para ilustrar esto de manera más completa, considere lo que podría pasar si 1253el código contenía una carga de A a cada lado de la barrera de lectura: 1254 1255 CPU 1 CPU 2 1256 ======================= ======================= 1257 { A = 0, B = 9 } 1258 STORE A=1 1259 <barrera de escritura> 1260 STORE B=2 1261 LOAD B 1262 LOAD A [primer load de A] 1263 <rbarrera de lectura> 1264 LOAD A [segundo load de A] 1265 1266Aunque las dos cargas de A ocurren después de la carga de B, ambas pueden 1267obtener diferentes valores: 1268 1269 +-------+ : : : : 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 | 1280 | : : | | 1281 | : : | | 1282 | +-------+ | | 1283 | | A->0 |------>| 1st | 1284 | +-------+ | | 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 : : +-------+ 1290 1291Pero puede ser que la actualización a A desde la CPU 1 se vuelva 1292perceptible para la CPU 2 antes de que la barrera de lectura se complete de 1293todos modos: 1294 1295 +-------+ : : : : 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 | 1306 | : : | | 1307 \ : : | | 1308 \ +-------+ | | 1309 ---->| A->1 |------>| 1st | 1310 +-------+ | | 1311 rrrrrrrrrrrrrrrrr | | 1312 +-------+ | | 1313 | A->1 |------>| 2nd | 1314 +-------+ | | 1315 : : +-------+ 1316 1317La garantía es que la segunda carga siempre dará como resultado A == 1 si 1318la carga de B resultó en B == 2. No existe tal garantía para la primera 1319carga de A; esto puede dar como resultado A == 0 o A == 1. 1320 1321 1322BARRERAS DE MEMORIA DE LECTURA FRENTE A ESPECULACIÓN DE CARGA 1323------------------------------------------------------------- 1324 1325Muchas CPU especulan con las cargas: es decir, ven que necesitarán cargar 1326un elemento de la memoria, y encuentran un momento en el que no están 1327usando el bus para ningún otra carga, y también en la carga por adelantado, 1328aunque en realidad no lo hayan llegado a ese punto en el flujo de ejecución 1329de instrucciones todavía. Esto permite que la instrucción de carga real 1330potencialmente complete de inmediato, porque la CPU ya tiene el valor a 1331mano. 1332 1333Puede resultar que la CPU en realidad no necesitara el valor, tal vez 1334porque una condición eludió la carga, en cuyo caso puede descartar el valor 1335o simplemente almacenar en caché para su uso posterior. 1336 1337Considere: 1338 1339 CPU 1 CPU 2 1340 ======================= ======================= 1341 LOAD B 1342 DIVIDE } Instrucciones de división 1343 DIVIDE } tardan mucho en terminar 1344 LOAD A 1345 1346donde DIVIDE es DIVIDIR. Que podría aparecer como esto: 1347 1348 : : +-------+ 1349 +-------+ | | 1350 --->| B->2 |------>| | 1351 +-------+ | CPU 2 | 1352 : :DIVIDE | | 1353 +-------+ | | 1354 La CPU ocupada con la división ---> --->| A->0 |~~~~ | | 1355 especula sobre el LOAD de A +-------+ ~ | | 1356 : : ~ | | 1357 : :DIVIDE | | 1358 : : ~ | | 1359 Una vez completadas las divisiones --> : : ~-->| | 1360 la CPU puede realizar el : : | | 1361 LOAD con efecto inmediato : : +-------+ 1362 1363 1364Colocando una barrera de lectura o una barrera de dependencia de dirección 1365justo antes de la segundo carga: 1366 1367 1368 1369 CPU 1 CPU 2 1370 ======================= ======================= 1371 LOAD B 1372 DIVIDE 1373 DIVIDE 1374 <rbarrera de lectura> 1375 LOAD A 1376 1377obligará a reconsiderar cualquier valor obtenido especulativamente en una 1378medida dependiente del tipo de barrera utilizada. Si no se hizo ningún 1379cambio en la ubicación de memoria especulada, entonces el valor especulado 1380solo se usará: 1381 1382 : : +-------+ 1383 +-------+ | | 1384 --->| B->2 |------>| | 1385 +-------+ | CPU 2 | 1386 : :DIVIDE | | 1387 +-------+ | | 1388 La CPU ocupada con la división ---> --->| A->0 |~~~~ | | 1389 especula sobre el LOAD de A +-------+ ~ | | 1390 : : ~ | | 1391 : :DIVIDE | | 1392 : : ~ | | 1393 : : ~ | | 1394 rrrrrrrrrrrrrrrr~ | | 1395 : : ~ | | 1396 : : ~-->| | 1397 : : | | 1398 : : +-------+ 1399 1400 1401pero si había una actualización o una invalidación de otra CPU pendiente, 1402entonces la especulación será cancelada y el valor recargado: 1403 1404 : : +-------+ 1405 +-------+ | | 1406 --->| B->2 |------>| | 1407 +-------+ | CPU 2 | 1408 : :DIVIDE | | 1409 +-------+ | | 1410 La CPU ocupada con la división ---> --->| A->0 |~~~~ | | 1411 especula sobre el LOAD de A +-------+ ~ | | 1412 : : ~ | | 1413 : :DIVIDE | | 1414 : : ~ | | 1415 : : ~ | | 1416 rrrrrrrrrrrrrrrrr | | 1417 +-------+ | | 1418 La especulación es descartada ---> --->| A->1 |------>| | 1419 y un valor actualizado +-------+ | | 1420 es conseguido : : +-------+ 1421 1422ATOMICIDAD MULTICOPIA 1423--------------------- 1424 1425La atomicidad multicopia es una noción profundamente intuitiva sobre el 1426orden que no es siempre proporcionada por los sistemas informáticos reales, 1427a saber, que un determinada store se vuelve visible al mismo tiempo para 1428todos las CPU o, alternativamente, que todas las CPU acuerdan el orden en 1429que todos los stores se vuelven visibles. Sin embargo, el soporte para 1430atomicidad multicopia completa descartaría valiosas optimizaciones 1431hardware, por lo que una versión más débil conocida como ``otra atomicidad 1432multicopia'' en cambio, solo garantiza que un store dado se vuelva visible 1433al mismo tiempo en todas las -otras- CPUs. El resto de este documento 1434discute esta versión más débil, pero por brevedad lo llamaremos simplemente 1435``atomicidad multicopia''. 1436 1437El siguiente ejemplo demuestra la atomicidad multicopia: 1438 1439 CPU 1 CPU 2 CPU 3 1440 ======================= ======================= ======================= 1441 { X = 0, Y = 0 } 1442 STORE X=1 r1=LOAD X (reads 1) LOAD Y (reads 1) 1443 <barrera general> <barrera de lectura> 1444 STORE Y=r1 LOAD X 1445 1446Suponga que la carga de la CPU 2 desde X devuelve 1, que luego almacena en 1447Y, y la carga de la CPU 3 desde Y devuelve 1. Esto indica que el store de 1448la CPU 1 a X precede a la carga de la CPU 2 desde X y el store de esa CPU 2 1449a Y precede la carga de la CPU 3 desde Y. Además, las barreras de memoria 1450garantizan que la CPU 2 ejecuta su carga antes que su almacenamiento, y la 1451CPU 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?" 1453 1454Debido a que la carga de la CPU 3 desde X en cierto sentido viene después 1455de la carga de la CPU 2, es natural esperar que la carga de la CPU 3 desde 1456X deba devolver 1. Esta expectativa se deriva de la atomicidad multicopia: 1457si una carga que se ejecuta en la CPU B sigue una carga de la misma 1458variable que se ejecuta en la CPU A (y la CPU A no almacenó originalmente 1459el valor que leyó), entonces en sistemas atómicos multicopia, la carga de 1460la CPU B debe devolver el mismo valor que hizo la carga de la CPU A o algún 1461valor posterior. Sin embargo, el kernel Linux no requiere que los sistemas 1462sean atómicos multicopia. 1463 1464El uso de una barrera de memoria general en el ejemplo anterior compensa 1465cualquier falta de atomicidad multicopia. En el ejemplo, si la carga de la 1466CPU 2 de X devuelve 1 y la carga de la CPU 3 de Y devuelve 1, entonces la 1467carga de la CPU 3 desde X debe de hecho también devolver 1. 1468 1469Sin embargo, las dependencias, las barreras de lectura y las barreras de 1470escritura no siempre son capaces de compensar la atomicidad no multicopia. 1471Por ejemplo, supongamos que la barrera general de la CPU 2 se elimina del 1472ejemplo anterior, dejando solo la dependencia de datos que se muestra a 1473continuación: 1474 1475 CPU 1 CPU 2 CPU 3 1476 ======================= ======================= ======================= 1477 { X = 0, Y = 0 } 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) 1481 1482Esta sustitución permite que la atomicidad no multicopia se desenfrene: en 1483este ejemplo, es perfectamente legal que la carga de la CPU 2 desde X 1484devuelva 1, la carga de la CPU 3 desde Y devuelva 1, y su carga desde X 1485tenga valor 0. 1486 1487El punto clave es que aunque la dependencia de datos de la CPU 2 ordena su 1488carga y store, no garantiza ordenar el store de la CPU 1. De forma que, si 1489este ejemplo se ejecuta en un sistema atómico no multicopia donde las CPU 1 1490y 2 comparten un buffer de almacenamiento o un nivel de caché, la CPU 2 1491podría tener acceso anticipado de escritura a CPU 1. Por lo tanto, se 1492requieren barreras generales para garantizar que todas las CPU acurden el 1493orden combinado de accesos múltiples. 1494 1495Las barreras generales pueden compensar no solo la atomicidad no 1496multicopia, pero también pueden generar orden adicional que puede asegurar 1497que -todas- las CPU percibirán el mismo orden de -todas- las operaciones. 1498Por el contrario, una cadena de parejas de liberación-adquisición no 1499proporciona este orden adicional, lo que significa que solo se garantiza 1500que las CPU de la cadena estén de acuerdo en el orden combinado de los 1501accesos. Por ejemplo, cambiando a código C en deferencia al fantasma de 1502Herman Hollerith: 1503 1504 int u, v, x, y, z; 1505 1506 void cpu0(void) 1507 { 1508 r0 = smp_load_acquire(&x); 1509 WRITE_ONCE(u, 1); 1510 smp_store_release(&y, 1); 1511 } 1512 1513 void cpu1(void) 1514 { 1515 r1 = smp_load_acquire(&y); 1516 r4 = READ_ONCE(v); 1517 r5 = READ_ONCE(u); 1518 smp_store_release(&z, 1); 1519 } 1520 1521 void cpu2(void) 1522 { 1523 r2 = smp_load_acquire(&z); 1524 smp_store_release(&x, 1); 1525 } 1526 1527 void cpu3(void) 1528 { 1529 WRITE_ONCE(v, 1); 1530 smp_mb(); 1531 r3 = READ_ONCE(u); 1532 } 1533 1534Dado que cpu0(), cpu1() y cpu2() participan en una cadena de parejas 1535smp_store_release()/smp_load_acquire(), el siguiente resultado estaría 1536prohibido: 1537 1538 r0 == 1 && r1 == 1 && r2 == 1 1539 1540Además, debido a la relación liberación-adquisición entre cpu0() y cpu1(), 1541cpu1() debe ver las escrituras de cpu0(), de modo que el siguiente 1542resultado estaría prohibido: 1543 1544 r1 == 1 && r5 == 0 1545 1546Sin embargo, el orden proporcionado por una cadena de 1547liberación-adquisición es local a las CPU que participan en esa cadena y no 1548se aplica a cpu3(), al menos aparte de los stores. Por lo tanto, es posible 1549el siguiente resultado: 1550 1551 r0 == 0 && r1 == 1 && r2 == 1 && r3 == 0 && r4 == 0 1552 1553Por otro lado, también el siguiente resultado es posible: 1554 1555 r0 == 0 && r1 == 1 && r2 == 1 && r3 == 0 && r4 == 0 && r5 == 1 1556 1557Aunque cpu0(), cpu1() y cpu2() verán sus respectivas lecturas y escrituras 1558en orden, las CPU que no participan en la cadena de liberación-adquisición 1559pueden estar en desacuerdo con el orden. Este desacuerdo se debe al hecho 1560de que las instrucciones de barrera de memoria débiles utilizadas para 1561implementar smp_load_acquire() y smp_store_release() no son necesarios para 1562ordenar stores anteriores contra cargas posteriores en todos los casos. 1563Esto significa que cpu3() puede ver el store de cpu0() suceder -después- de 1564la carga de cpu1() desde v, aunque tanto cpu0() como cpu1() están de 1565acuerdo en que estas dos operaciones ocurrieron en el orden previsto. 1566 1567Sin embargo, tenga en cuenta que smp_load_acquire() no es mágico. En 1568particular, simplemente lee de su argumento en orden. Es decir, -no- 1569asegura que se leerá cualquier valor en particular. Por lo tanto, los 1570siguiente resultados son posibles: 1571 1572 r0 == 0 && r1 == 0 && r2 == 0 && r5 == 0 1573 1574Tenga en cuenta que este resultado puede ocurrir incluso en un mítico 1575sistema, consistente en secuencia, donde nunca se reordena nada. 1576 1577Para reiterar, si su código requiere un orden completo de todas las 1578operaciones, utilice barreras generales en todo momento. 1579 1580 1581============================== 1582BARRERAS EXPLÍCITAS DEL KERNEL 1583============================== 1584 1585El kernel Linux tiene una variedad de diferentes barreras que actúan a 1586diferentes niveles: 1587 1588 (*) Barrera del compilador. 1589 1590 (*) Barreras de memoria de la CPU. 1591 1592 1593BARRERA DEL COMPILADOR 1594----------------------- 1595 1596El kernel de Linux tiene una función de barrera del compilador explícita 1597que evita que el el compilador mueva los accesos a la memoria de cualquier 1598lado al otro: 1599 1600 barrier(); 1601 1602Esta es una barrera general: no hay variantes de barrier() para casos de 1603lectura-lectura o escritura-escritura. Sin embargo, READ_ONCE() y 1604WRITE_ONCE() pueden ser considerado como formas débiles de barrier() que 1605afectan solo específicos accesos marcados por READ_ONCE() o WRITE_ONCE(). 1606 1607La función barrier() produce los siguientes efectos: 1608 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. 1614 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 1617 ese loop. 1618 1619Las funciones READ_ONCE() y WRITE_ONCE() pueden evitar cualquier cantidad 1620de optimizaciones que, si bien son perfectamente seguras en código de un 1621solo subproceso, pueden resultar fatales en código concurrente. Aquí hay 1622algunos ejemplos de tal tipo de optimizaciones: 1623 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: 1628 1629 a[0] = x; 1630 a[1] = x; 1631 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 1634 siguiente manera: 1635 1636 a[0] = READ_ONCE(x); 1637 a[1] = READ_ONCE(x); 1638 1639 En resumen, READ_ONCE() y WRITE_ONCE() proporcionan coherencia de 1640 caché para accesos desde múltiples CPUs a una sola variable. 1641 1642 (*) El compilador tiene derecho a juntar cargas sucesivas de la misma 1643 variable. Tal fusión puede hacer que el compilador "optimice" el 1644 siguiente código: 1645 1646 while (tmp = a) 1647 hacer_algo_con(tmp); 1648 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: 1652 1653 if (tmp = a) 1654 for (;;) 1655 hacer_algo_con(tmp); 1656 1657 Use READ_ONCE() para evitar que el compilador le haga esto: 1658 1659 while (tmp = READ_ONCE(a)) 1660 hacer_algo_con(tmp); 1661 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 1666 ejemplo anterior: 1667 1668 while (tmp = a) 1669 hacer_algo_con(tmp); 1670 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 1673 concurrente: 1674 1675 while (a) 1676 hacer_algo_con(a); 1677 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(). 1682 1683 De nuevo, use READ_ONCE() para evitar que el compilador haga esto: 1684 1685 while (tmp = READ_ONCE(a)) 1686 hacer_algo_con(tmp); 1687 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. 1694 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 1698 código: 1699 1700 while (tmp = a) 1701 hacer_algo_con(tmp); 1702 1703 En esto: 1704 1705 do { } while (0); 1706 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: 1713 1714 while (tmp = READ_ONCE(a)) 1715 hacer_algo_con(tmp); 1716 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: 1721 1722 while ((tmp = READ_ONCE(a)) % MAX) 1723 hacer_algo_con(tmp); 1724 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 1728 la variable 'a'.) 1729 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: 1736 1737 a = 0; 1738 ... Código que no almacena la variable a ... 1739 a = 0; 1740 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' 1744 mientras tanto. 1745 1746 Use WRITE_ONCE() para evitar que el compilador haga este tipo de 1747 suposición equivocada: 1748 1749 WRITE_ONCE(a, 0); 1750 ... Código que no almacena la variable a ... 1751 WRITE_ONCE(a, 0); 1752 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: 1756 1757 void nivel_de_procesamiento(void) 1758 { 1759 msg = ACQUIRE_mensaje(); 1760 flag = true; 1761 } 1762 1763 void controlador_interrupcion(void) 1764 { 1765 if (flag) 1766 procesar_mensaje(msg); 1767 } 1768 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: 1772 1773 void nivel_de_procesamiento(void) 1774 { 1775 flag = true; 1776 msg = ACQUIRE_mensaje(); 1777 } 1778 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: 1782 1783 void nivel_de_procesamiento(void) 1784 { 1785 WRITE_ONCE(msg, ACQUIRE_mensaje()); 1786 WRITE_ONCE(flag, true); 1787 } 1788 1789 void controlador_interrupcion(void) 1790 { 1791 if (READ_ONCE(flag)) 1792 procesar_mensaje(READ_ONCE(msg)); 1793 } 1794 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().) 1805 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. 1809 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 1818 necesita hacerlo. 1819 1820 (*) El compilador tiene derecho a inventar stores para una variable, 1821 como en el siguiente ejemplo: 1822 1823 if (a) 1824 b = a; 1825 else 1826 b = 42; 1827 1828 El compilador podría ahorrar un branch al optimizar esto de la 1829 siguiente manera: 1830 1831 b = 42; 1832 if (a) 1833 b = a; 1834 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 1840 manera: 1841 1842 if (a) 1843 WRITE_ONCE(b, a); 1844 else 1845 WRITE_ONCE(b, 42); 1846 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. 1851 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: 1861 1862 p = 0x00010002; 1863 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: 1872 1873 struct __attribute__((__packed__)) foo { 1874 short a; 1875 int b; 1876 short c; 1877 }; 1878 struct foo foo1, foo2; 1879 ... 1880 1881 foo2.a = foo1.a; 1882 foo2.b = foo1.b; 1883 foo2.c = foo1.c; 1884 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 1891 en este ejemplo: 1892 1893 foo2.a = foo1.a; 1894 WRITE_ONCE(foo2.b, READ_ONCE(foo1.b)); 1895 foo2.c = foo1.c; 1896 1897Aparte de esto, nunca es necesario usar READ_ONCE() y WRITE_ONCE() en una 1898variable que se ha marcado como volátil. Por ejemplo, dado que 'jiffies' 1899está marcado como volátil, nunca es necesario usar READ_ONCE(jiffies). La 1900razón de esto es que READ_ONCE() y WRITE_ONCE() se implementan como 1901conversiones volátiles, lo que no tiene efecto cuando su argumento ya está 1902marcado como volátil. 1903 1904Tenga en cuenta que estas barreras del compilador no tienen un efecto 1905directo en la CPU, que luego puede reordenar las cosas como quiera. 1906 1907 1908BARRERAS DE MEMORIA DE LA CPU 1909----------------------------- 1910 1911El kernel de Linux tiene siete barreras básicas de memoria de CPU: 1912 1913TIPO OBLIGATORIO SMP CONDICIONAL 1914======================= =============== =============== 1915GENERAL mb() smp_mb() 1916WRITE wmb() smp_wmb() 1917READ rmb() smp_rmb() 1918DEPEDENCIA DE DIRECCIÓN READ_ONCE() 1919 1920 1921Todas las barreras de memoria, excepto las barreras de dependencia de 1922direcciones, implican una barrera del compilador. Las dependencias de 1923direcciones no imponen ningún orden de compilación adicional. 1924 1925Además: en el caso de las dependencias de direcciones, se esperaría que el 1926compilador emita las cargas en el orden correcto (por ejemplo, `a[b]` 1927tendría que cargar el valor de b antes de cargar a[b]), sin embargo, no hay 1928garantía alguna en la especificación de C sobre que el compilador no puede 1929especular el valor de b (por ejemplo, es igual a 1) y carga a[b] antes que 1930b (ej. tmp = a[1]; if (b != 1) tmp = a[b]; ). También existe el problema de 1931que un compilador vuelva a cargar b después de haber cargado a[b], teniendo 1932así una copia más nueva de b que a[b]. Aún no se ha conseguido un consenso 1933acerca de estos problemas, sin embargo, el macro READ_ONCE() es un buen 1934lugar para empezar a buscar. 1935 1936Las barreras de memoria SMP se reducen a barreras de compilador cuando se 1937compila a monoprocesador, porque se supone que una CPU parecerá ser 1938auto-consistente, y ordenará correctamente los accesos superpuestos 1939respecto a sí misma. Sin embargo, consulte la subsección "Guests de 1940máquinas virtuales" mas adelante. 1941 1942[!] Tenga en cuenta que las barreras de memoria SMP _deben_ usarse para 1943controlar el orden de referencias a memoria compartida en sistemas SMP, 1944aunque el uso de bloqueo en su lugar sea suficiente. 1945 1946Las barreras obligatorias no deben usarse para controlar los efectos de 1947SMP, ya que dichas barreras imponen una sobrecarga innecesaria en los 1948sistemas SMP y UP. Se pueden, sin embargo, usar para controlar los efectos 1949MMIO en los accesos a través de ventanas E/S de memoria relajada. Estas 1950barreras son necesarias incluso en sistemas que no son SMP, ya que afectan 1951al orden en que las operaciones de memoria aparecen en un dispositivo, al 1952prohibir tanto al compilador como a la CPU que sean reordenados. 1953 1954 1955Hay algunas funciones de barrera más avanzadas: 1956 1957 (*) smp_store_mb(var, valor) 1958 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. 1962 1963 1964 (*) smp_mb__before_atomic(); 1965 (*) smp_mb__after_atomic(); 1966 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. 1974 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). 1977 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: 1980 1981 obj->dead = 1; 1982 smp_mb__before_atomic(); 1983 atomic_dec(&obj->ref_count); 1984 1985 Esto asegura que la marca de muerte en el objeto se perciba como 1986 fijada *antes* de que disminuya el contador de referencia. 1987 1988 Consulte Documentation/atomic_{t,bitops}.txt para obtener más 1989 información. 1990 1991 1992 (*) dma_wmb(); 1993 (*) dma_rmb(); 1994 (*) dma_mb(); 1995 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. 1999 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: 2005 2006 if (desc->status != DEVICE_OWN) { 2007 /* no leer los datos hasta que tengamos el descriptor */ 2008 dma_rmb(); 2009 2010 /* leer/modificar datos */ 2011 read_data = desc->data; 2012 desc->data = write_data; 2013 2014 /* flush de modificaciones antes de la actualización de estado */ 2015 dma_wmb(); 2016 2017 /* asignar propiedad */ 2018 desc->status = DEVICE_OWN; 2019 2020 /* notificar al dispositivo de nuevos descriptores */ 2021 writel(DESC_NOTIFY, doorbell); 2022 } 2023 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í. 2033 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 2037 consistente. 2038 2039 (*) pmem_wmb(); 2040 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. 2044 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(). 2051 2052 Para la carga desde memoria persistente, las barreras de memoria de 2053 lectura existentes son suficientes para garantizar el orden de 2054 lectura. 2055 2056 (*) io_stop_wc(); 2057 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. 2064 2065========================================= 2066BARRERAS DE MEMORIA IMPLÍCITAS DEL KERNEL 2067========================================= 2068 2069Algunas de las otras funciones en el kernel Linux implican barreras de 2070memoria, entre estas encontramos funciones de bloqueo y planificación 2071("scheduling"). 2072 2073Esta especificación es una garantía _mínima_; cualquier arquitectura 2074particular puede proporcionar garantías más sustanciales, pero no se puede 2075confiar en estas fuera de código específico de arquitectura. 2076 2077 2078FUNCIONES DE ADQUISICIÓN DE CERROJO 2079----------------------------------- 2080 2081El kernel Linux tiene una serie de abstracciones de bloqueo: 2082 2083 (*) spin locks (cerrojos en loop) 2084 (*) R/W spin lock (cerrojos de escritura/lectura) 2085 (*) mutex 2086 (*) semáforos 2087 (*) R/W semáforos 2088 2089En todos los casos existen variantes de las operaciones "ACQUIRE" y 2090"RELEASE" para cada uno de ellos. Todas estas operaciones implican ciertas 2091barreras: 2092 2093 (1) Implicaciones de la operación ACQUIRE: 2094 2095 Las operaciones de memoria emitidas después del ACQUIRE se completarán 2096 después de que la operación ACQUIRE haya finalizado. 2097 2098 Las operaciones de memoria emitidas antes de ACQUIRE pueden 2099 completarse después que la operación ACQUIRE se ha completado. 2100 2101 (2) Implicaciones de la operación RELEASE: 2102 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. 2105 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. 2108 2109 (3) Implicación de ACQUIRE vs ACQUIRE: 2110 2111 Todas las operaciones ACQUIRE emitidas antes de otra operación 2112 ACQUIRE serán completadas antes de esa operación ACQUIRE. 2113 2114 (4) Implicación de ACQUIRE vs RELEASE: 2115 2116 Todas las operaciones ACQUIRE emitidas antes de una operación RELEASE 2117 serán completadas antes de la operación RELEASE. 2118 2119 (5) Implicación de ACQUIRE condicional fallido: 2120 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. 2126 2127[!] Nota: una de las consecuencias de que los cerrojos en ACQUIRE y RELEASE 2128sean barreras unidireccionales, es que los efectos de las instrucciones 2129fuera de una sección crítica pueden filtrarse al interior de la sección 2130crítica. 2131 2132No se puede suponer que un ACQUIRE seguido de una RELEASE sea una barrera 2133de memoria completa dado que es posible que un acceso anterior a ACQUIRE 2134suceda después del ACQUIRE, y un acceso posterior a la RELEASE suceda antes 2135del RELEASE, y los dos accesos puedan entonces cruzarse: 2136 2137 *A = a; 2138 ACQUIRE M 2139 RELEASE M 2140 *B = b; 2141 2142puede ocurrir como: 2143 2144 ACQUIRE M, STORE *B, STORE *A, RELEASE M 2145 2146Cuando ACQUIRE y RELEASE son bloqueo de adquisición y liberación, 2147respectivamente, este mismo orden puede ocurrir si el cerrojo ACQUIRE y 2148RELEASE son para la misma variable de bloqueo, pero solo desde la 2149perspectiva de otra CPU que no tiene ese bloqueo. En resumen, un ACQUIRE 2150seguido de un RELEASE NO puede entenderse como una barrera de memoria 2151completa. 2152 2153De manera similar, el caso inverso de un RELEASE seguido de un ACQUIRE no 2154implica una barrera de memoria completa. Por lo tanto, la ejecución de la 2155CPU de los tramos críticos correspondientes a la RELEASE y la ACQUIRE 2156pueden cruzarse, de modo que: 2157 2158 *A = a; 2159 RELEASE M 2160 ACQUIRE N 2161 *B = b; 2162 2163puede ocurrir como: 2164 2165 ACQUIRE N, STORE *B, STORE *A, RELEASE M 2166 2167Podría parecer que este nuevo orden podría introducir un punto muerto. 2168Sin embargo, esto no puede suceder porque si tal punto muerto amenazara 2169con suceder, el RELEASE simplemente se completaría, evitando así el 2170interbloqueo ("deadlock", punto muerto). 2171 2172 ¿Por qué funciona esto? 2173 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. 2177 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 2186 éxito. 2187 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 2194 cualquier caso. 2195 2196Es posible que los cerrojos y los semáforos no proporcionen ninguna 2197garantía de orden en sistemas compilados en UP, por lo que no se puede 2198contar con tal situación para lograr realmente nada en absoluto, 2199especialmente con respecto a los accesos de E/S, a menos que se combinen 2200con operaciones de inhabilitación de interrupciones. 2201 2202Consulte también la sección "Efectos de barrera adquiriendo intra-CPU". 2203 2204 2205Como ejemplo, considere lo siguiente: 2206 2207 *A = a; 2208 *B = b; 2209 ACQUIRE 2210 *C = c; 2211 *D = d; 2212 RELEASE 2213 *E = e; 2214 *F = f; 2215 2216La siguiente secuencia de eventos es aceptable: 2217 2218 ACQUIRE, {*F,*A}, *E, {*C,*D}, *B, RELEASE 2219 2220 [+] Tenga en cuenta que {*F,*A} indica un acceso combinado. 2221 2222Pero ninguno de los siguientes lo son: 2223 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 2228 2229 2230 2231FUNCIONES DE DESACTIVACIÓN DE INTERRUPCIONES 2232-------------------------------------------- 2233 2234Las funciones que deshabilitan interrupciones (equivalentes a ACQUIRE) y 2235habilitan interrupciones (equivalentes a RELEASE) actuarán únicamente como 2236barrera del compilador. Por consiguiente, si la memoria o la E/S requieren 2237barreras en tal situación, deben ser provistas por algún otro medio. 2238 2239 2240FUNCIONES DE DORMIR Y DESPERTAR 2241------------------------------- 2242 2243Dormir y despertar son eventos marcados ("flagged") en los datos globales 2244que se pueden ver como una interacción entre dos piezas de datos: el estado 2245de la task (hilo, proceso, tarea) que espera el evento y los datos globales 2246utilizados para indicar el evento. Para asegurarse de que estos parezcan 2247suceder en el orden correcto, las primitivas para comenzar el proceso de ir 2248a dormir, y las primitivas para iniciar un despertar implican ciertas 2249barreras. 2250 2251En primer lugar, el agente durmiente normalmente sigue algo similar a esta 2252secuencia de eventos: 2253 2254 for (;;) { 2255 set_current_state(TASK_UNINTERRUPTIBLE); 2256 if (evento_indicado) 2257 break; 2258 schedule(); // planificar 2259 } 2260 2261Una barrera de memoria general se obtiene automáticamente mediante 2262set_current_state() después de haber alterado el estado de la tarea: 2263 2264 CPU 1 2265 =============================== 2266 set_current_state(); // hacer_estado_actual() 2267 smp_store_mb(); 2268 STORE current->state 2269 <barrera general> 2270 LOAD evento_indicado 2271 2272set_current_state() puede estar envuelto por: 2273 2274 prepare_to_wait(); // preparese_para_esperar(); 2275 prepare_to_wait_exclusive(); // prepararse_para_solo_esperar(); 2276 2277que por lo tanto también implican una barrera de memoria general después de 2278establecer el estado. Toda la secuencia anterior está disponible en varias 2279formas, todas las cuales obtienen la barrera de memoria en el lugar 2280correcto: 2281 2282 wait_event(); 2283 wait_event_interruptible(); 2284 wait_event_interruptible_exclusive(); 2285 wait_event_interruptible_timeout(); 2286 wait_event_killable(); 2287 wait_event_timeout(); 2288 wait_on_bit(); 2289 wait_on_bit_lock(); 2290 2291 2292En segundo lugar, el código que realiza una activación normalmente se 2293asemeja a algo como esto: 2294 2295 evento_indicado = 1; 2296 wake_up(&event_wait_queue); // despertar 2297 2298o: 2299 2300 evento_indicado = 1; 2301 wake_up_process(event_daemon); // despertar proceso 2302 2303wake_up() ejecuta una barrera de memoria general si despierta algo. Si no 2304despierta nada, entonces una barrera de memoria puede o no ser ejecutada; 2305no debe confiar en ello. La barrera se produce antes del acceso al estado 2306de la tarea. En particular, se encuentra entre el STORE para indicar el 2307evento y el STORE para configurar TASK_RUNNING (hilo ejecutando): 2308 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) 2316 STORE task->state 2317 2318donde "task" es el subproceso que se está despertando y es igual al 2319"current" (hilo actual) de la CPU 1. 2320 2321Para reiterar, se garantiza la ejecución de una barrera de memoria general 2322mediante wake_up() si algo está realmente despierto, pero de lo contrario 2323no existe tal garantía. Para entender esto, considere la siguiente 2324secuencia de eventos, donde X e Y son ambos cero inicialmente: 2325 2326 CPU 1 CPU 2 2327 =============================== =============================== 2328 X = 1; Y = 1; 2329 smp_mb(); wake_up(); 2330 LOAD Y LOAD X 2331 2332Si ocurre una reactivación ("wakeup"), una (al menos) de las dos cargas 2333debe ver 1. Si, por otro lado, no ocurre una reactivación, ambas cargas 2334pueden ver 0. 2335 2336wake_up_process() siempre ejecuta una barrera de memoria general. La 2337barrera, de nuevo, ocurre antes de que se acceda al estado del hilo. En 2338particular, si wake_up(), en el fragmento anterior, fuera reemplazado por 2339una llamada a wake_up_process(), las dos cargas verían 1, garantizado. 2340 2341Las funciones de activación disponibles incluyen: 2342 2343 complete(); 2344 wake_up(); 2345 wake_up_all(); 2346 wake_up_bit(); 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(); 2353 wake_up_locked(); 2354 wake_up_locked_poll(); 2355 wake_up_nr(); 2356 wake_up_poll(); 2357 wake_up_process(); 2358 2359En términos de orden de la memoria, todas estas funciones proporcionan las 2360mismas garantías que un wake_up() (o más fuertes). 2361 2362[!] Tenga en cuenta que las barreras de la memoria implicadas por el 2363durmiente y el despierto _no_ ordenan varios stores antes del despertar con 2364respecto a cargas de los valores guardados después de que el durmiente haya 2365llamado a set_current_state(). Por ejemplo, si el durmiente hace: 2366 2367 set_current_state(TASK_INTERRUPTIBLE); 2368 if (evento_indicado) 2369 break; 2370 __set_current_state(TASK_RUNNING); 2371 hacer_algo(my_data); 2372 2373y el que despierta hace: 2374 2375 my_data = valor; 2376 evento_indicado = 1; 2377 wake_up(&event_wait_queue); 2378 2379no existe garantía de que el cambio a event_indicated sea percibido por 2380el durmiente de manera que venga después del cambio a my_data. En tal 2381circunstancia, el código en ambos lados debe sacar sus propias barreras de 2382memoria entre los separados accesos a datos. Por lo tanto, el durmiente 2383anterior debería hacer: 2384 2385 set_current_state(TASK_INTERRUPTIBLE); 2386 if (evento_indicado) { 2387 smp_rmb(); 2388 hacer_algo(my_data); 2389 } 2390 2391y el que despierta debería hacer: 2392 2393 my_data = value; 2394 smp_wmb(); 2395 evento_indicado = 1; 2396 wake_up(&event_wait_queue); 2397 2398FUNCIONES VARIAS 2399---------------- 2400 2401Otras funciones que implican barreras: 2402 2403 (*) schedule() y similares implican barreras completas de memoria. 2404 2405 2406======================================== 2407EFECTOS DE BARRERA ADQUIRIENDO INTRA-CPU 2408======================================== 2409 2410En los sistemas SMP, las primitivas de bloqueo proveen una forma más 2411sustancial de barrera: una que afecta el orden de acceso a la memoria en 2412otras CPU, dentro del contexto de conflicto en cualquier bloqueo en 2413particular. 2414 2415 2416ADQUISICIÓN VS ACCESOS A MEMORIA 2417-------------------------------- 2418 2419Considere lo siguiente: el sistema tiene un par de spinlocks (M) y (Q), y 2420tres CPU; entonces la siguiente secuencia de eventos debería ocurrir: 2421 2422 CPU 1 CPU 2 2423 =============================== =============================== 2424 WRITE_ONCE(*A, a); WRITE_ONCE(*E, e); 2425 ACQUIRE M ACQUIRE Q 2426 WRITE_ONCE(*B, b); WRITE_ONCE(*F, f); 2427 WRITE_ONCE(*C, c); WRITE_ONCE(*G, g); 2428 RELEASE M RELEASE Q 2429 WRITE_ONCE(*D, d); WRITE_ONCE(*H, h); 2430 2431Entonces no hay garantía sobre en qué orden verá la CPU 3 los accesos a *A 2432hasta que *H ocurra, además de las restricciones impuestas por los bloqueos 2433separados en las distintas CPUs. Podría, por ejemplo, ver: 2434 2435 *E, ACQUIRE M, ACQUIRE Q, *G, *C, *F, *A, *B, RELEASE Q, *D, *H, RELEASE M 2436 2437Pero no verá ninguno de: 2438 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 2443 2444======================================== 2445¿DÓNDE SE NECESITAN BARRERAS DE MEMORIA? 2446======================================== 2447 2448Bajo operación normal, el re-ordenamiento de una operación de memoria 2449generalmente no va a suponer un problema, ya que para una pieza de código 2450lineal de un solo subproceso seguirá pareciendo que funciona correctamente, 2451incluso si está en un kernel SMP. Existen, sin embargo, cuatro 2452circunstancias en las que reordenar definitivamente _podría_ ser un 2453problema: 2454 2455 (*) Interacción entre procesadores. 2456 2457 (*) Operaciones atómicas. 2458 2459 (*) Acceso a dispositivos. 2460 2461 (*) Interrupciones. 2462 2463 2464INTERACCIÓN ENTRE PROCESADORES 2465------------------------------ 2466 2467Cuando se da un sistema con más de un procesador, más de una CPU en el 2468sistema puede estar trabajando en el mismo conjunto de datos al mismo 2469tiempo. Esto puede causar problemas de sincronización, y la forma habitual 2470de tratar con estos es utilizar cerrojos. Sin embargo, los cerrojos son 2471bastante caros, por lo que puede ser preferible operar sin el uso de un 2472cerrojo a ser posible. En cuyo caso, es posible que las operaciones que 2473afectan a ambas CPU deban ordenarse cuidadosamente para evitar un 2474funcionamiento incorrecto. 2475 2476Considere, por ejemplo, la ruta lenta del semáforo R/W. Aquí hay un proceso 2477de espera en cola del semáforo, en virtud de que tiene una parte de su pila 2478vinculada a la lista de procesos en espera del semáforo: 2479 2480 struct rw_semaphore { 2481 ... 2482 spinlock_t lock; 2483 struct list_head waiters; 2484 }; 2485 2486 struct rwsem_waiter { 2487 struct list_head list; 2488 struct task_struct *task; 2489 }; 2490 2491Para despertar a un proceso que espera ("waiter") en particular, las 2492funciones up_read() o up_write() tienen que: 2493 2494 (1) leer el siguiente puntero del registro de este proceso que espera, 2495 para saber dónde está el registro del siguiente waiter; 2496 2497 (2) leer el puntero a la estructura de tareas del waiter; 2498 2499 (3) borrar el puntero de la tarea para decirle al waiter que se le ha dado 2500 el semáforo; 2501 2502 (4) llamar a wake_up_process() en la tarea; y 2503 2504 (5) liberar la referencia retenida en la estructura de tareas del waiter. 2505 2506En otras palabras, tiene que realizar esta secuencia de eventos: 2507 2508 LOAD waiter->list.next; 2509 LOAD waiter->task; 2510 STORE waiter->task; 2511 CALL wakeup 2512 RELEASE task 2513 2514y si alguno de estos pasos ocurre fuera de orden, entonces todo puede que 2515funcione defectuosamente. 2516 2517Una vez que se ha puesto en cola y soltado el bloqueo de semáforo, el 2518proceso que espera no consigue el candado de nuevo; en cambio, solo espera 2519a que se borre su puntero de tarea antes de continuar. Dado que el registro 2520está en la pila del proceso que espera, esto significa que si el puntero de 2521la tarea se borra _antes_ de que se lea el siguiente puntero de la lista, 2522otra CPU podría comenzar a procesar el proceso que espera y podría romper 2523el stack del proceso que espera antes de que la función up*() tenga la 2524oportunidad de leer el puntero que sigue. 2525 2526Considere entonces lo que podría suceder con la secuencia de eventos 2527anterior: 2528 2529 CPU 1 CPU 2 2530 =============================== =============================== 2531 down_xxx() 2532 Poner waiter en la "queue" (cola) 2533 Dormir 2534 up_yyy() 2535 LOAD waiter->task; 2536 STORE waiter->task; 2537 Despertado por otro evento 2538 <preempt> 2539 Reanudar el procesamiento 2540 down_xxx() regresa 2541 llamada a foo() 2542 foo() estropea *waiter 2543 </preempt> 2544 LOAD waiter->list.next; 2545 --- OOPS --- 2546 2547Esto podría solucionarse usando el bloqueo de semáforo, pero luego la 2548función down_xxx() tiene que obtener innecesariamente el spinlock 2549nuevamente, después de ser despertado el hilo. 2550 2551La forma de lidiar con esto es insertar una barrera de memoria SMP general: 2552 2553 LOAD waiter->list.next; 2554 LOAD waiter->task; 2555 smp_mb(); 2556 STORE waiter->task; 2557 CALL wakeup 2558 RELEASE task 2559 2560En este caso, la barrera garantiza que todos los accesos a memoria antes de 2561la barrera parecerán suceder antes de todos los accesos a memoria después 2562de dicha barrera con respecto a las demás CPU del sistema. _No_ garantiza 2563que todos los accesos a memoria antes de la barrera se completarán en el 2564momento en que la instrucción de la barrera en sí se complete. 2565 2566En un sistema UP, donde esto no sería un problema, la función smp_mb() es 2567solo una barrera del compilador, asegurándose así de que el compilador 2568emita las instrucciones en el orden correcto sin realmente intervenir en la 2569CPU. Como solo hay un CPU, la lógica de orden de dependencias de esa CPU se 2570encargará de todo lo demás. 2571 2572 2573OPERACIONES ATÓMICAS 2574-------------------- 2575 2576Si bien son, técnicamente, consideraciones de interacción entre 2577procesadores, las operaciones atómicas se destacan especialmente porque 2578algunas de ellas implican barreras de memoria completa y algunas otras no, 2579pero se confía mucho en ellos en su conjunto a lo largo del kernel. 2580 2581Consulte Documentation/atomic_t.txt para obtener más información. 2582 2583 2584ACCESO A DISPOSITIVOS 2585--------------------- 2586 2587Un driver puede ser interrumpido por su propia rutina de servicio de 2588interrupción y, por lo tanto, las dos partes del driver pueden interferir 2589con los intentos de controlar o acceder al dispositivo. 2590 2591Esto puede aliviarse, al menos en parte, desactivando las interrupciones 2592locales (una forma de bloqueo), de modo que las operaciones críticas sean 2593todas contenidas dentro la sección de interrupción desactivada en el 2594controlador. Mientras la interrupción del driver está ejecutando la rutina, 2595es posible que el "core" del controlador no se ejecute en la misma CPU y no 2596se permita que su interrupción vuelva a ocurrir hasta que la interrupción 2597actual haya sido resuelta, por lo tanto, el controlador de interrupción no 2598necesita bloquearse contra esto. 2599 2600Sin embargo, considere un driver que estaba hablando con una tarjeta 2601ethernet que tiene un registro de direcciones y un registro de datos. Si 2602el core de ese controlador habla con la tarjeta estando en desactivación de 2603interrupción y luego se invoca el controlador de interrupción del 2604controlador: 2605 2606 IRQ LOCALES DESACTIVADAS 2607 writew(ADDR, 3); 2608 writew(DATA, y); 2609 IRQ LOCALES ACTIVADAS 2610 <interrupción> 2611 writew(ADDR, 4); 2612 q = readw(DATA); 2613 </interrupción> 2614 2615El almacenamiento en el registro de datos puede ocurrir después del segundo 2616almacenamiento en el registro de direcciones si las reglas de orden son lo 2617suficientemente relajadas: 2618 2619 STORE *ADDR = 3, STORE *ADDR = 4, STORE *DATA = y, q = LOAD *DATA 2620 2621Si se relajan las reglas de orden, se debe asumir que los accesos 2622realizados dentro de la sección con interrupción deshabilitada pueden 2623filtrarse fuera de esta y pueden intercalarse con accesos realizados en una 2624interrupción - y viceversa - a menos que se utilicenn barreras implícita o 2625explícitas. 2626 2627Normalmente, esto no será un problema porque los accesos de E/S realizados 2628dentro de tales secciones incluirán operaciones de carga síncronas en 2629registros E/S estrictamente ordenados, que forman barreras de E/S 2630implícitas. 2631 2632 2633Una situación similar puede ocurrir entre una rutina de interrupción y dos 2634rutinas ejecutándose en separadas CPU que se comunican entre sí. Si tal 2635caso es probable, entonces se deben usar bloqueos de desactivación de 2636interrupciones para garantizar el orden. 2637 2638 2639===================================== 2640 Efectos de barrera de E/S del kernel 2641===================================== 2642 2643La interfaz con periféricos a través de accesos de E/S es profundamente 2644específica para cada arquitectura y dispositivo. Por lo tanto, los drivers 2645que son inherentemente no portátiles pueden depender de comportamientos 2646específicos de sus sistemas de destino, con el fin de lograr la 2647sincronización de la manera más ligera posible. Para drivers que deseen ser 2648portátiles entre múltiples arquitecturas e implementaciones de bus, el 2649kernel ofrece una serie de funciones de acceso que proporcionan varios 2650grados de garantías de orden: 2651 2652 (*) readX(), writeX(): 2653 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: 2658 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. 2663 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. 2670 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 2677 la transferencia. 2678 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. 2686 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 2693 writeX(): 2694 2695 writel(42, DEVICE_REGISTER_0); // Llega al dispositivo ... 2696 readl(DEVICE_REGISTER_0); 2697 udelay(1); 2698 writel(42, DEVICE_REGISTER_1); // al menos 1us antes de esto.... 2699 2700Las propiedades de orden de los punteros __iomem obtenidos con valores de 2701atributos que no sean los valores por defecto (por ejemplo, los devueltos 2702por ioremap_wc()) son específicos de la arquitectura subyacente y, por lo 2703tanto, las garantías enumeradas anteriormente no pueden por lo general ser 2704aseguradas para accesos a este tipo de "mappings" (asignaciones). 2705 2706 (*) readX_relaxed(), writeX_relaxed(): 2707 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. 2715 2716 (*) readsX(), writesX(): 2717 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. 2723 2724 (*) inX(), outX(): 2725 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 2730 como un argumento. 2731 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). 2738 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. 2744 2745 (*) insX(), outsX(): 2746 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. 2750 2751 (*) ioreadX(), iowriteX(): 2752 2753 Estos funcionarán adecuadamente para el tipo de acceso que realmente están 2754 haciendo, ya sea inX()/outX() o readX()/writeX(). 2755 2756Con la excepción de los puntos de entrada (insX(), outsX(), readsX() y 2757writesX()), todo lo anterior supone que el periférico subyacente es 2758little-endian y, por lo tanto, realizará operaciones de intercambio de 2759bytes en arquitecturas big-endian. 2760 2761 2762=========================================== 2763MODELO DE ORDEN MÍNIMO DE EJECUCIÓN ASUMIDO 2764=========================================== 2765 2766Debe suponerse que la CPU conceptual está débilmente ordenada, pero que 2767mantiene la apariencia de causalidad del programa con respecto a sí misma. 2768Algunas CPU (como i386 o x86_64) están más limitadas que otras (como 2769powerpc o frv), por lo que el caso más relajado (es decir, DEC Alpha) se 2770debe asumir fuera de código específico de arquitectura. 2771 2772Esto significa que se debe considerar que la CPU ejecutará su flujo de 2773instrucciones en el orden que se quiera - o incluso en paralelo - siempre 2774que si una instrucción en el flujo depende de una instrucción anterior, 2775entonces dicha instrucción anterior debe ser lo suficientemente completa[*] 2776antes de que la posterior instrucción puede proceder; en otras palabras: 2777siempre que la apariencia de causalidad se mantenga. 2778 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. 2782 2783Una CPU puede también descartar cualquier secuencia de instrucciones que 2784termine sin tener efecto final. Por ejemplo, si dos instrucciones 2785adyacentes cargan un valor inmediato en el mismo registro, la primera puede 2786descartarse. 2787 2788 2789De manera similar, se debe suponer que el compilador podría reordenar la 2790corriente de instrucciones de la manera que crea conveniente, nuevamente 2791siempre que la apariencia de causalidad se mantenga. 2792 2793 2794===================================== 2795EFECTOS DE LA MEMORIA CACHÉ DE LA CPU 2796===================================== 2797 2798La forma en que se perciben las operaciones de memoria caché en todo el 2799sistema se ve afectada, hasta cierto punto, por los cachés que se 2800encuentran entre las CPU y la memoria, y por el sistema de coherencia en 2801memoria que mantiene la consistencia de estado en el sistema. 2802 2803En cuanto a la forma en que una CPU interactúa con otra parte del sistema a 2804través del caché, el sistema de memoria tiene que incluir los cachés de la 2805CPU y barreras de memoria, que en su mayor parte actúan en la interfaz 2806entre la CPU y su caché (las barreras de memoria lógicamente actúan sobre 2807la línea de puntos en el siguiente diagrama): 2808 2809 <--- CPU ---> : <----------- Memoria -----------> 2810 : 2811 +--------+ +--------+ : +--------+ +-----------+ 2812 | Core | | Cola | : | Cache | | | +---------+ 2813 | CPU | | de | : | CPU | | | | | 2814 | |--->| acceso |----->| |<-->| | | | 2815 | | | a | : | | | |--->| Memoria | 2816 | | | memoria| : | | | | | | 2817 +--------+ +--------+ : +--------+ | Mecanismo | | | 2818 : | de | +---------+ 2819 : | Coherencia| 2820 : | de la | +--------+ 2821 +--------+ +--------+ : +--------+ | cache | | | 2822 | Core | | Cola | : | Cache | | | | | 2823 | CPU | | de | : | CPU | | |--->| Dispos | 2824 | |--->| acceso |----->| |<-->| | | itivo | 2825 | | | a | : | | | | | | 2826 | | | memoria| : | | | | +--------+ 2827 +--------+ +--------+ : +--------+ +-----------+ 2828 : 2829 : 2830 2831Aunque es posible que una carga o store en particular no aparezca fuera de 2832la CPU que lo emitió, ya que puede haber sido satisfecha dentro del propio 2833caché de la CPU, seguirá pareciendo como si el acceso total a la memoria 2834hubiera tenido lugar para las otras CPUs, ya que los mecanismos de 2835coherencia de caché migrarán la cacheline sobre la CPU que accede y se 2836propagarán los efectos en caso de conflicto. 2837 2838El núcleo de la CPU puede ejecutar instrucciones en el orden que considere 2839adecuado, siempre que parezca mantenerse la causalidad esperada del 2840programa. Algunas de las instrucciones generan operaciones de carga y 2841almacenamiento que luego van a la cola de accesos a memoria a realizar. El 2842núcleo puede colocarlos en la cola en cualquier orden que desee, y 2843continuar su ejecución hasta que se vea obligado a esperar que una 2844instrucción sea completada. 2845 2846De lo que se ocupan las barreras de la memoria es de controlar el orden en 2847que los accesos cruzan, desde el lado de la CPU, hasta el lado de memoria, 2848y el orden en que los otros observadores perciben los efectos en el sistema 2849que sucedan por esto. 2850 2851[!] Las barreras de memoria _no_ son necesarias dentro de una CPU 2852determinada, ya que las CPU siempre ven sus propias cargas y stores como si 2853hubieran sucedido en el orden del programa. 2854 2855[!] Los accesos a MMIO u otros dispositivos pueden pasar por alto el 2856sistema de caché. Esto depende de las propiedades de la ventana de memoria 2857a través de la cual se accede a los dispositivos y/o el uso de 2858instrucciones especiales de comunicación con dispositivo que pueda tener la 2859CPU. 2860 2861 2862COHERENCIA DE CACHÉ FRENTE A DMA 2863--------------------------------- 2864 2865No todos los sistemas mantienen coherencia de caché con respecto a los 2866dispositivos que realizan DMA. En tales casos, un dispositivo que intente 2867DMA 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 2869se hayan vuelto a escribir en la RAM todavía. Para hacer frente a esto, la 2870parte apropiada del kernel debe vaciar los bits superpuestos de caché en 2871cada CPU (y tal vez también invalidarlos). 2872 2873Además, los datos enviados por DMA a RAM, por un dispositivo, pueden ser 2874sobrescritos por líneas de caché sucias que se escriben de nuevo en la RAM 2875desde el caché de una CPU, después de que el dispositivo haya puesto sus 2876propios datos, o las líneas de caché presentes en el caché de la CPU pueden 2877simplemente ocultar el hecho de que la memoria RAM se haya actualizado, 2878hasta el momento en que la caché se descarta de la memoria caché de la CPU 2879y se vuelve a cargar. Para hacer frente a esto, la parte apropiada del 2880kernel debe invalidar los bits superpuestos del caché en cada CPU. 2881 2882Consulte Documentation/core-api/cachetlb.rst para obtener más información 2883sobre administración de la memoria caché. 2884 2885 2886COHERENCIA DE CACHÉ FRENTE A MMIO 2887--------------------------------- 2888 2889La E/S mapeada en memoria generalmente se lleva a cabo a través de 2890ubicaciones de memoria que forman parte de una ventana del espacio de 2891memoria de la CPU, que tiene diferentes propiedades asignadas que la 2892ventana habitual dirigida a RAM. 2893 2894Entre dichas propiedades, suele existir el hecho de que tales accesos 2895eluden el almacenamiento en caché por completo e ir directamente a los 2896buses del dispositivo. Esto significa que los accesos MMIO pueden, en 2897efecto, superar los accesos a la memoria caché que se emitieron 2898anteriormente. Una barrera de memoria no es suficiente en tal caso, sino 2899que el caché debe ser vaciado entre la escritura de la memoria caché, y el 2900acceso MMIO, si los dos son de cualquier manera dependiente. 2901 2902 2903======================= 2904COSAS QUE HACEN LAS CPU 2905======================= 2906 2907Un programador podría dar por sentado que la CPU realizará las operaciones 2908de memoria exactamente en el orden especificado, de modo que si a la CPU se 2909entrega, por ejemplo, el siguiente fragmento de código a ejecutar: 2910 2911 a = READ_ONCE(*A); 2912 WRITE_ONCE(*B, b); 2913 c = READ_ONCE(*C); 2914 d = READ_ONCE(*D); 2915 WRITE_ONCE(*E, e); 2916 2917esperarían entonces que la CPU complete la operación de memoria para cada 2918instrucción antes de pasar a la siguiente, lo que lleva a una definida 2919secuencia de operaciones vistas por observadores externos en el sistema: 2920 2921 LOAD *A, STORE *B, LOAD *C, LOAD *D, STORE *E. 2922 2923La realidad es, por supuesto, mucho más intrincada. Para muchas CPU y 2924compiladores, la anterior suposición no se sostiene porque: 2925 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; 2929 2930 (*) las cargas se pueden hacer especulativamente, y el resultado es 2931 descartado si resulta innecesario; 2932 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; 2936 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; 2939 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 2945 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. 2950 2951Entonces, digamos que lo que otra CPU podría observar en el fragmento de 2952código anterior es: 2953 2954 LOAD *A, ..., LOAD {*C,*D}, STORE *E, STORE *B 2955 2956 (Donde "LOAD {*C,*D}" es una carga combinada) 2957 2958 2959Sin embargo, se garantiza que una CPU es autoconsistente: verá que sus 2960 _propios_ accesos parecen estar correctamente ordenados, sin necesidad de 2961barrera de memoria. Por ejemplo con el siguiente código: 2962 2963 U = READ_ONCE(*A); 2964 WRITE_ONCE(*A, V); 2965 WRITE_ONCE(*A, W); 2966 X = READ_ONCE(*A); 2967 WRITE_ONCE(*A, Y); 2968 Z = READ_ONCE(*A); 2969 2970y asumiendo que no hay intervención de una influencia externa, se puede 2971suponer que el resultado final se parecerá a: 2972 2973 U == el valor original de *A 2974 X == W 2975 Z == Y 2976 *A == Y 2977 2978El código anterior puede hacer que la CPU genere la secuencia completa de 2979accesos de memoria: 2980 2981 U=LOAD *A, STORE *A=V, STORE *A=W, X=LOAD *A, STORE *A=Y, Z=LOAD *A 2982 2983en ese orden, pero, sin intervención, la secuencia puede contener casi 2984cualquier combinación de elementos combinados o descartados, siempre que la 2985perspectiva del programa del mundo siga siendo consistente. Tenga en cuenta 2986que READ_ONCE() y WRITE_ONCE() -no- son opcionales en el ejemplo anterior, 2987ya que hay arquitecturas donde una CPU determinada podría reordenar cargas 2988sucesivas en la misma ubicación. En tales arquitecturas, READ_ONCE() y 2989WRITE_ONCE() hacen lo que sea necesario para evitar esto, por ejemplo, en 2990Itanium los casts volátiles utilizados por READ_ONCE() y WRITE_ONCE() hacen 2991que GCC emita las instrucciones especiales ld.acq y st.rel 2992(respectivamente) que impiden dicha reordenación. 2993 2994El compilador también puede combinar, descartar o diferir elementos de la 2995secuencia antes incluso de que la CPU los vea. 2996 2997Por ejemplo: 2998 2999 *A = V; 3000 *A = W; 3001 3002puede reducirse a: 3003 3004 *A = W; 3005 3006ya que, sin una barrera de escritura o WRITE_ONCE(), puede que se asuma 3007que el efecto del almacenamiento de V a *A se pierde. Similarmente: 3008 3009 *A = Y; 3010 Z = *A; 3011 3012puede, sin una barrera de memoria o un READ_ONCE() y WRITE_ONCE(), esto 3013sea reducido a: 3014 3015 *A = Y; 3016 Z = Y; 3017 3018y la operación LOAD nunca aparezca fuera de la CPU. 3019 3020 3021Y LUEGO ESTÁ EL ALFA 3022-------------------- 3023 3024La CPU DEC Alpha es una de las CPU más relajadas que existen. No solo eso, 3025algunas versiones de la CPU Alpha tienen un caché de datos dividido, lo que 3026les permite tener dos líneas de caché relacionadas semánticamente, 3027actualizadas en momentos separados. Aquí es donde la barrera de dependencia 3028de dirección realmente se vuelve necesaria, ya que se sincronizan ambos 3029cachés con el sistema de coherencia de memoria, lo que hace que parezca un 3030cambio en el puntero, frente a que los nuevos datos se produzcan en el 3031orden correcto. 3032 3033Alpha define el modelo de memoria del kernel Linux, aunque a partir de 3034v4.15, la adición al kernel de Linux de smp_mb() a READ_ONCE() en Alpha 3035redujo en gran medida su impacto en el modelo de memoria. 3036 3037 3038GUESTS DE MÁQUINAS VIRTUALES 3039----------------------------- 3040 3041Los "guests" (invitados) que se ejecutan en máquinas virtuales pueden verse 3042afectados por los efectos de SMP incluso si el "host" (huésped) en sí se 3043compila sin compatibilidad con SMP. Este es un efecto de la interacción con 3044un host SMP mientras ejecuta un kernel UP. El uso obligatorio de barreras 3045para este caso de uso sería posible, pero a menudo no son óptimas. 3046 3047Para hacer frente a este caso de manera óptima, están disponibles macros de 3048bajo nivel virt_mb() etc. Estas tienen el mismo efecto que smp_mb(), etc. 3049cuando SMP está habilitado, pero generan código idéntico para sistemas SMP 3050y no SMP. Por ejemplo, los invitados de máquinas virtuales debería usar 3051virt_mb() en lugar de smp_mb() al sincronizar contra un (posiblemente SMP) 3052anfitrión. 3053 3054Estos son equivalentes a sus contrapartes smp_mb() etc. en todos los demás 3055aspectos, en particular, no controlan los efectos MMIO: para controlar los 3056efectos MMIO, utilice barreras obligatorias. 3057 3058 3059================ 3060EJEMPLOS DE USOS 3061================ 3062 3063BUFFERS CIRCULARES 3064------------------ 3065 3066Las barreras de memoria se pueden utilizar para implementar almacenamiento 3067en búfer circular, sin necesidad de un cerrojo para serializar al productor 3068con el consumidor. Vea: 3069 3070 Documentation/core-api/circular-buffers.rst 3071 3072para más detalles. 3073 3074 3075=========== 3076REFERENCIAS 3077=========== 3078 3079Alpha AXP Architecture Reference Manual, Segunda Edición (por Sites & Witek, 3080Digital Press) 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 3085 3086AMD64 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 3089 3090ARM Architecture Reference Manual (ARMv8, for ARMv8-A architecture profile) 3091 Capítulo B2: The AArch64 Application Level Memory Model 3092 3093IA-32 Intel Architecture Software Developer's Manual, Volumen 3: 3094System Programming Guide 3095 Capítulo 7.1: Locked Atomic Operations 3096 Capítulo 7.2: Memory Ordering 3097 Capítulo 7.4: Serializing Instructions 3098 3099The 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 3103 3104Storage in the PowerPC (por Stone and Fitzgerald) 3105 3106UltraSPARC Programmer Reference Manual 3107 Capítulo 5: Memory Accesses and Cacheability 3108 Capítulo 15: Sparc-V9 Memory Models 3109 3110UltraSPARC III Cu User's Manual 3111 Capítulo 9: Memory Models 3112 3113UltraSPARC IIIi Processor User's Manual 3114 Capítulo 8: Memory Models 3115 3116UltraSPARC Architecture 2005 3117 Capítulo 9: Memory 3118 Appendix D: Formal Specifications of the Memory Models 3119 3120UltraSPARC T1 Supplement to the UltraSPARC Architecture 2005 3121 Capítulo 8: Memory Models 3122 Appendix F: Caches and Cache Coherency 3123 3124Solaris Internals, Core Kernel Architecture, p63-68: 3125 Capítulo 3.3: Hardware Considerations for Locks and 3126 Synchronization 3127 3128Unix Systems for Modern Architectures, Symmetric Multiprocessing and Caching 3129for Kernel Programmers: 3130 Capítulo 13: Other Memory Models 3131 3132Intel Itanium Architecture Software Developer's Manual: Volumen 1: 3133 Sección 2.6: Speculation 3134 Sección 4.4: Memory Access 3135