8.7. Núcleo
Ahora la memoria de subsección hotplug es totalmente compatible
Anteriormente, algunas plataformas alineaban las regiones de memoria física, como los Módulos Duales en Línea (DIMM) y los conjuntos de intercalación a los límites de memoria de 64MiB. Sin embargo, como el subsistema de conexión en caliente de Linux utiliza un tamaño de memoria de 128MiB, la conexión en caliente de nuevos dispositivos hacía que se superpusieran varias regiones de memoria en una única ventana de memoria de conexión en caliente. Consecuentemente, esto causó un fallo en el listado de los espacios de nombres de memoria persistente disponibles con el siguiente o similar trazado de llamada:
WARNING: CPU: 38 PID: 928 at arch/x86/mm/init_64.c:850 add_pages+0x5c/0x60 [..] RIP: 0010:add_pages+0x5c/0x60 [..] Call Trace: devm_memremap_pages+0x460/0x6e0 pmem_attach_disk+0x29e/0x680 [nd_pmem] ? nd_dax_probe+0xfc/0x120 [libnvdimm] nvdimm_bus_probe+0x66/0x160 [libnvdimm]
Esta actualización corrige el problema y admite el subsistema de hotplug de Linux para permitir que varias regiones de memoria compartan una única ventana de memoria de hotplug.
(BZ#1724969)
La corrupción de datos ahora desencadena un BUG en lugar de un mensaje WARN
Con esta mejora, las corrupciones de la lista en lib/list_debug.
c ahora desencadenan un BUG, que genera un informe con un vmcore
. Anteriormente, cuando se encontraba una corrupción de datos, se generaba un simple WARN, que probablemente pasaba desapercibido. Con el set CONFIG_BUG_ON_DATA_CORRUPTION
, el kernel ahora crea un crash y dispara un BUG en respuesta a la corrupción de datos. Esto evita daños mayores y reduce el riesgo de seguridad. El kdump
ahora genera un vmcore
, lo que mejora la notificación de errores de corrupción de datos.
(BZ#1714330)
La compatibilidad con la tarjeta Intel Carlsville
está disponible pero no se ha verificado en RHEL 8.2
El soporte de la tarjeta Intel Carlsville
está disponible pero no ha sido probado en Red Hat Enterprise Linux 8.2.
(BZ#1720227)
RPS y XPS ya no colocan trabajos en CPUs aisladas
Anteriormente, el mecanismo de cola de software Receive Packet Steering (RPS) y el mecanismo de selección de cola de transmisión Transmit Packet Steering (XPS) asignaban trabajos en todos los conjuntos de CPU, incluidas las CPU aisladas. En consecuencia, esto podía provocar un pico de latencia inesperado en un entorno de tiempo real cuando una carga de trabajo sensible a la latencia utilizaba la misma CPU en la que se ejecutaban los trabajos RPS o XPS. Con esta actualización, la función store_rps_map()
no incluye ninguna CPU aislada a efectos de configuración de RPS. Del mismo modo, los controladores del kernel utilizados para la configuración de XPS respetan el aislamiento de la CPU. Como resultado, RPS y XPS ya no colocan trabajos en CPUs aisladas en el escenario descrito. Si se configura una CPU aislada en el archivo /sys/devices/pci*/net/dev/queues/rx-*/rps_cpus
, aparece el siguiente error:
Error: "-bash: echo:write error: Argumento inválido"
Sin embargo, la configuración manual de una CPU aislada en el archivo /sys/devices/pci*/net/dev/queues/tx-*/xps_cpus
asigna con éxito los trabajos XPS en la CPU aislada.
Tenga en cuenta que una carga de trabajo de red en un entorno con CPUs aisladas es probable que experimente alguna variación de rendimiento.
(BZ#1867174)