Lines Matching refs:una
30 Este documento no es una especificación; es intencionalmente (por motivos
32 pretende ser una guía para usar las diversas barreras de memoria
39 De nuevo, este documento no es una especificación de lo que Linux espera
47 (2) proporcionar una guía sobre cómo utilizar las barreras disponibles.
49 Tenga en cuenta que una arquitectura puede proporcionar más que el
53 Tenga en cuenta también que es posible que una barrera no valga (sea no-op)
153 relajado, y una CPU en realidad puede realizar las operaciones de memoria
194 Además, los stores asignados por una CPU al sistema de memoria pueden no
206 Aquí hay una dependencia obvia de la dirección, ya que el valor cargado en
222 de control es muy importante. Por ejemplo, imagine una tarjeta ethernet con
242 Hay algunas garantías mínimas que se pueden esperar de una CPU:
255 emite una instrucción de barrera de memoria, de modo que una CPU DEC
263 (*) Los loads y stores superpuestos dentro de una CPU en particular
284 Y hay una serie de cosas que _deben_ o _no_ deben asumirse:
339 pueden causar una actualización a una campo para corromper el valor de
356 ya sea un objeto de tipo escalar, o una secuencia máxima
366 estructura anidada y el otro no, o si las dos están separados por una
384 Las barreras de memoria son este tipo de intervenciones. Imponen una
389 sistema pueden usar una variedad de trucos para mejorar el rendimiento,
413 Se puede considerar que una CPU envía una secuencia de operaciones de
415 stores _antes_ de una barrera de escritura ocurrirán _antes_ de todos
426 Una barrera de dependencia de dirección es una forma más débil de
430 load), una barrera de dependencia de dirección sería necesaria para
434 Una barrera de dependencia de direcciones es una ordenación parcial en
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
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
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
506 Esto actúa como una barrera permeable unidireccional. Garantiza que
512 Las operaciones de memoria que ocurren antes de una operación ACQUIRE
515 Una operación ACQUIRE casi siempre debe estar emparejada con una
521 Esto también actúa como una barrera permeable unidireccional.
527 Las operaciones de memoria que ocurren después de una operación
532 RELEASE+ACQUIRE NO garantiza actuar como una barrera de memoria
533 completa. Sin embargo, después de un ACQUIRE de una variable dada,
536 otras palabras, dentro de la sección crítica de una variable dada,
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
552 interacción entre dos CPU o entre una CPU y un dispositivo. Si se puede
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
574 (*) No hay garantía de que la emisión de una barrera de memoria en una CPU
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
589 una barrera de memoria entre las CPU, pero es posible que no lo hagan
628 que no implica una barrera de dependencia de direcciones.
630 Hay una clara dependencia de dirección aquí, y parecería que al final de
641 Si bien esto puede parecer una falla en el mantenimiento de la coherencia
645 Para lidiar con esto, READ_ONCE() proporciona una barrera de dependencia
658 Esto refuerza la ocurrencia de una de las dos implicaciones, y previene la
666 una línea de caché impar y la variable B podría almacenarse en una línea de
673 No se requiere una barrera de dependencia de dirección para ordenar
692 resultado está prohibido, incluso sin una barrera de dependencia de
705 Tenga en cuenta que el orden proporcionado por una dependencia de dirección
726 Una dependencia de control load-load (de carga a carga) requiere una
727 barrera de memoria de lectura completa, no simplemente una barrera
738 Esto no tendrá el efecto deseado porque no hay una dependencia de dirección
739 real, sino más bien una dependencia de control que la CPU puede
859 agregar una barrier(), pero esto no ayuda. El condicional se ha ido, y la
873 Tenga en cuenta una vez más que los stores de 'b' difieren. Si fueran
893 al compilador para emitir código para una carga dada, no fuerza al
931 Tenga muy en cuenta que el orden proporcionado por una dependencia de
993 Una barrera de adquisición se empareja con una barrera de liberación, pero
996 una barrera de dependencia de dirección, una dependencia de control, una
997 barrera de adquisición, una barrera de liberación, una barrera de lectura
998 o una barrera general. Del mismo modo, una barrera de lectura se empareja
999 con una de dependencia de control o barrera de dependencia de dirección con
1000 una barrera de escritura, una barrera de adquisición, una barrera de
1001 liberación o una barrera general:
1139 Sin embargo, si se colocara una barrera de dependencia de dirección entre
1180 Y en tercer lugar, una barrera de lectura actúa como un orden parcial sobre
1216 Sin embargo, si se colocara una barrera de lectura entre la carga de B y la
1253 el código contenía una carga de A a cada lado de la barrera de lectura:
1334 porque una condición eludió la carga, en cuyo caso puede descartar el valor
1364 Colocando una barrera de lectura o una barrera de dependencia de dirección
1377 obligará a reconsiderar cualquier valor obtenido especulativamente en una
1401 pero si había una actualización o una invalidación de otra CPU pendiente,
1425 La atomicidad multicopia es una noción profundamente intuitiva sobre el
1431 hardware, por lo que una versión más débil conocida como ``otra atomicidad
1457 si una carga que se ejecuta en la CPU B sigue una carga de la misma
1464 El uso de una barrera de memoria general en el ejemplo anterior compensa
1498 Por el contrario, una cadena de parejas de liberación-adquisición no
1534 Dado que cpu0(), cpu1() y cpu2() participan en una cadena de parejas
1546 Sin embargo, el orden proporcionado por una cadena de
1585 El kernel Linux tiene una variedad de diferentes barreras que actúan a
1596 El kernel de Linux tiene una función de barrera del compilador explícita
1602 Esta es una barrera general: no hay variantes de barrier() para casos de
1640 caché para accesos desde múltiples CPUs a una sola variable.
1662 (*) El compilador tiene derecho a recargar una variable, por ejemplo,
1695 (*) El compilador está en su derecho de omitir una carga por completo si
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
1720 una macro de preprocesador con el valor 1:
1742 lo que bien podría omitir el segundo store. Esto supondría una fatal
1771 una victoria para código de un solo subproceso:
1798 también accede a 'flag' y 'msg', por ejemplo, una interrupción anidada
1820 (*) El compilador tiene derecho a inventar stores para una variable,
1853 acceder con una sola instrucción de referencia de memoria, evite el
1856 accesos menores. Por ejemplo, dada una arquitectura que tiene
1867 tanto, esta optimización puede ser una victoria en un código de un
1889 resultaría en una carga con desgarro en 'foo1.b' y store del desgarro
1897 Aparte de esto, nunca es necesario usar READ_ONCE() y WRITE_ONCE() en una
1922 direcciones, implican una barrera del compilador. Las dependencias de
1932 así una copia más nueva de b que a[b]. Aún no se ha conseguido un consenso
1937 compila a monoprocesador, porque se supone que una CPU parecerá ser
1947 SMP, ya que dichas barreras imponen una sobrecarga innecesaria en los
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.
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
1972 atomic_set. Un ejemplo común donde se puede requerir una barrera es
1976 implican una barrera de memoria (como set_bit y clear_bit).
1978 Como ejemplo, considere una pieza de código que marca un objeto como
2045 Por ejemplo, después de una escritura no temporal en la región pmem,
2073 Esta especificación es una garantía _mínima_; cualquier arquitectura
2081 El kernel Linux tiene una serie de abstracciones de bloqueo:
2116 Todas las operaciones ACQUIRE emitidas antes de una operación RELEASE
2123 recibieron una señal de desbloqueo mientras dormían esperando que el
2127 [!] Nota: una de las consecuencias de que los cerrojos en ACQUIRE y RELEASE
2129 fuera de una sección crítica pueden filtrarse al interior de la sección
2132 No se puede suponer que un ACQUIRE seguido de una RELEASE sea una barrera
2150 seguido de un RELEASE NO puede entenderse como una barrera de memoria
2154 implica una barrera de memoria completa. Por lo tanto, la ejecución de la
2190 encontrará una barrera de memoria, que forzará la operación de desbloqueo
2192 haber una carrera de desbloqueo del sueño ("sleep-unlock race"), pero la
2244 que se pueden ver como una interacción entre dos piezas de datos: el estado
2277 que por lo tanto también implican una barrera de memoria general después de
2292 En segundo lugar, el código que realiza una activación normalmente se
2303 wake_up() ejecuta una barrera de memoria general si despierta algo. Si no
2304 despierta nada, entonces una barrera de memoria puede o no ser ejecutada;
2321 Para reiterar, se garantiza la ejecución de una barrera de memoria general
2332 Si ocurre una reactivación ("wakeup"), una (al menos) de las dos cargas
2333 debe ver 1. Si, por otro lado, no ocurre una reactivación, ambas cargas
2336 wake_up_process() siempre ejecuta una barrera de memoria general. La
2339 una llamada a wake_up_process(), las dos cargas verían 1, garantizado.
2410 En los sistemas SMP, las primitivas de bloqueo proveen una forma más
2411 sustancial de barrera: una que afecta el orden de acceso a la memoria en
2448 Bajo operación normal, el re-ordenamiento de una operación de memoria
2449 generalmente no va a suponer un problema, ya que para una pieza de código
2467 Cuando se da un sistema con más de un procesador, más de una CPU en el
2477 de espera en cola del semáforo, en virtud de que tiene una parte de su pila
2551 La forma de lidiar con esto es insertar una barrera de memoria SMP general:
2567 solo una barrera del compilador, asegurándose así de que el compilador
2592 locales (una forma de bloqueo), de modo que las operaciones críticas sean
2600 Sin embargo, considere un driver que estaba hablando con una tarjeta
2623 filtrarse fuera de esta y pueden intercalarse con accesos realizados en una
2633 Una situación similar puede ocurrir entre una rutina de interrupción y dos
2649 kernel ofrece una serie de funciones de acceso que proporcionan varios
2666 subproceso de CPU, si emitido después de una adquisición posterior del
2708 Son similares a readX() y writeX(), pero proporcionan una garantía de
2736 acceder a una asignación con los valores de atributos de E/S
2739 Los drivers de dispositivos pueden esperar que outX() emita una
2740 transacción de escritura no publicada, que espera una respuesta de
2774 que si una instrucción en el flujo depende de una instrucción anterior,
2803 En cuanto a la forma en que una CPU interactúa con otra parte del sistema a
2831 Aunque es posible que una carga o store en particular no aparezca fuera de
2843 continuar su ejecución hasta que se vea obligado a esperar que una
2851 [!] Las barreras de memoria _no_ son necesarias dentro de una CPU
2875 desde el caché de una CPU, después de que el dispositivo haya puesto sus
2890 ubicaciones de memoria que forman parte de una ventana del espacio de
2918 instrucción antes de pasar a la siguiente, lo que lleva a una definida
2947 mecanismos de coherencia pueden aliviar esto, una vez que el store
2956 (Donde "LOAD {*C,*D}" es una carga combinada)
2959 Sin embargo, se garantiza que una CPU es autoconsistente: verá que sus
2970 y asumiendo que no hay intervención de una influencia externa, se puede
2987 ya que hay arquitecturas donde una CPU determinada podría reordenar cargas
3006 ya que, sin una barrera de escritura o WRITE_ONCE(), puede que se asuma
3012 puede, sin una barrera de memoria o un READ_ONCE() y WRITE_ONCE(), esto
3024 La CPU DEC Alpha es una de las CPU más relajadas que existen. No solo eso,