Perguntas[linux-kernel](unix)

O que é uma thread estacionada no contexto do kernel Linux? Uma thread que está em TASK_PARKEDestado?

Como esse estado difere de TASK_INTERRUPTIBLEe TASK_UNINTERRUPTIBLE?

De qual estado uma thread pode ser despertada mais rapidamente? Geralmente, e em casos específicos, se usada para espera: kthread_parkme / kthread_unparkem vez de [s]wait_event_... / [s]wake_up_...]?

Sei que as filas de espera aceitam vários garçons, mas estou interessado apenas em um único par de pessoas dormindo/acordando.

Ao configurar a alocação dinâmica de memória, o kernel do Linux precisa escolher um local para colocar seu heap, certo? Como ele evita sobrescrever sua própria pilha ou que a pilha cresça e sobrescreva o heap posteriormente?

Estou enfrentando uma queda significativa de desempenho ao usar o "rsync" para copiar arquivos pela rede de dentro de um contêiner ou cgroup com limites de memória no Oracle Linux 9.2. O problema ocorre com o Red Hat Compatible Kernel (RHCK) 5.14.0-284.11.1.el9_2.x86_64, mas não com o Unbreakable Enterprise Kernel (UEK) 5.15.0-101.103.2.1.el9uek.x86_64.

Detalhes: Configuração: Oracle Linux 9.2 com contêineres/cgroups com limites de memória. Problema: A velocidade de cópia de arquivos pela rede cai drasticamente quando os limites de memória são atingidos, especialmente quando o cache de páginas (arquivos inativos) fica cheio. Testes:

• Usando "rsync" de dentro de um contêiner ou um cgroup para copiar dados de uma fonte remota.
• Utilizando a replicação de dados PostgreSQL "pg_basebackup" entre dois contêineres PG (Líder vs. Réplica). Resultados:
• As altas velocidades iniciais (~100 MBps) caem significativamente (para ~1 MBps) quando os limites de memória são atingidos.

Comandos para reproduzir:

1. Crie um cgroup com limite de memória e execute o rsync: sudo systemd-run --scope --property=MemoryMax=1G rsync -av --progress rsync://<source_ip>/files /destination_path

2. Teste com drop_caches no sistema operacional de hospedagem durante rsync lento: free && sync && echo 3 > /proc/sys/vm/drop_caches && free Após o cache ser descartado, o rsync fica rápido novamente até que o limite de MEM seja atingido novamente

Observações:

• Quando o limite de memória do contêiner é atingido, o cache de páginas (arquivos inativos) fica cheio, levando à degradação da largura de banda da rede.
• Isso afeta, por exemplo, a replicação do PostgreSQL, causando atraso e potencial perda de dados.

Alguém mais já passou por esse problema? Quaisquer dicas ou sugestões sobre como lidar com isso corretamente (ou talvez soluções alternativas) seriam muito apreciadas!

Quando a memória é alocada via kmalloc(ou seja, alocação de cache slab como slab_alloc_node), ela retorna um endereço de memória virtual. Presumivelmente, ao acessar esse endereço virtual, o PTE correspondente (que traduz o endereço virtual para um endereço físico) já existe, permitindo a tradução de endereço porque o endereço do kernel não permite falha de página. Quem cria esse PTE e quando ele é criado?

Estou usando um sistema de 64 bits, não um de 32 bits. Em sistemas de 32 bits, entendo que há uma região de “memória baixa” (tipicamente dentro de 1 GiB), e que essa memória baixa é pré-mapeada para a memória física durante a inicialização.

No entanto, estou curioso sobre como isso funciona em sistemas de 64 bits. De acordo com esta postagem do StackOverflow ( https://stackoverflow.com/questions/30541036/will-physical-addresses-of-all-paging-structures-in-linux-be-mapped-in-the-page ), ele diz que em sistemas de 64 bits,

“todos os endereços físicos são sempre mapeados com um mapeamento Supervisor na metade do kernel do espaço de endereço.”

, E aqui ( Em qual tabela de páginas de processos o vmalloc() aloca nova memória? ) disse

as entradas da tabela de páginas para kmalloc já foram alocadas.

Quero verificar se isso é realmente verdade. Eis o motivo de meu ceticismo: suponha que minha máquina tenha 128 GiB de DRAM e cada PTE tenha 8 bytes. Então, apenas a tabela de páginas em si exigiria 256 MiB (128 GiB/4 KiB * 8 Byte). Mas quando executo numastat -m após a inicialização, o tamanho da PageTable não parece ser tão grande. Então, imagino o que realmente está acontecendo.

Estou com problemas ao usar dma_alloc_coherent(NULL, 1, &ack_physical_address, GFP_KERNEL); atingindo a desreferência de ponteiro nulo e, portanto, #PF. Quero criar um pequeno local de memória física contíguo de 1 byte.

Como posso descobrir desde qual versão do Linux uma função/macro da API do kernel está disponível ou sofreu alterações significativas (foi removida, houve alteração no tipo ou número de argumentos)?

Por exemplo, ao olhar a versão recente do , scatterlist.hme deparei com sg_alloc_table_from_pages_segment, que tem exatamente a funcionalidade necessária para meu módulo do kernel (driver). No entanto, a função, para minha decepção, ainda não está disponível na versão 5.10 para a qual o módulo do kernel foi desenvolvido, e terei que encontrar uma solução alternativa. Ainda assim, desejo oferecer suporte a futuras versões do kernel, caso realizemos uma atualização.

Normalmente, esses casos são tratados com cercas de pré-processador

#if LINUX_VERSION_CODE >= KERNEL_VERSION(...)
/*Version-specific implementation*/
#endif

Mas para aplicar esse padrão, preciso encontrar a versão do kernel na qual a função foi adicionada. Escanear manualmente todas as versões intermediárias do arquivo de cabeçalho seria uma tarefa de Sísifo.

Estou trabalhando em alguns scripts antigos que lidam com cpusets, portando para o openSUSE. Os scripts funcionavam bem com o openSUSE 15.5, mas agora com o 15.6 eles falham porque os /dev/cpusetarquivos que eles esperavam não estão lá. Na verdade, os arquivos estão todos lá, mas perderam o prefixo cpuset.em seus nomes.

Por exemplo, para um cpuset chamado sys, os scripts esperam manipular /dev/cpuset/sys/cpuset.cpus, mas o arquivo real parece ser chamado /dev/cpuset/sys/cpus. Esse padrão continua para todos os treze arquivos que no openSUSE 15.5 (e sistemas mais antigos) tinham nomes começando com cpuset.; os mesmos arquivos estão lá, mas sem o cpuset.prefixo.

Olhando para a página de referência do docs.kernel.org , a cpuset.*nomenclatura é a que está documentada. Alguma ideia de onde os arquivos sem o cpuset.prefixo vieram?

Mais informações: aqui está o /dev/cpuset/sysdiretório completo (onde sysestá o nome do cpuset) em uma máquina openSUSE Leap 15.5:

devuser@product:/dev/cpuset/sys> ls -al
total 0
drwxr-xr-x 2 root root 0 Feb 18 14:07 .
dr-xr-xr-x 3 root root 0 Feb 18 14:03 ..
-rw-r--r-- 1 root root 0 Feb 18 14:07 cgroup.clone_children
-rw-r--r-- 1 root root 0 Feb 18 14:07 cgroup.procs
-rw-r--r-- 1 root root 0 Feb 18 14:07 cpuset.cpu_exclusive
-rw-r--r-- 1 root root 0 Feb 18 14:07 cpuset.cpus
-r--r--r-- 1 root root 0 Feb 18 14:07 cpuset.effective_cpus
-r--r--r-- 1 root root 0 Feb 18 14:07 cpuset.effective_mems
-rw-r--r-- 1 root root 0 Feb 18 14:07 cpuset.mem_exclusive
-rw-r--r-- 1 root root 0 Feb 18 14:07 cpuset.mem_hardwall
-rw-r--r-- 1 root root 0 Feb 18 14:07 cpuset.memory_migrate
-r--r--r-- 1 root root 0 Feb 18 14:07 cpuset.memory_pressure
-rw-r--r-- 1 root root 0 Feb 18 14:07 cpuset.memory_spread_page
-rw-r--r-- 1 root root 0 Feb 18 14:07 cpuset.memory_spread_slab
-rw-r--r-- 1 root root 0 Feb 18 14:07 cpuset.mems
-rw-r--r-- 1 root root 0 Feb 18 14:07 cpuset.sched_load_balance
-rw-r--r-- 1 root root 0 Feb 18 14:07 cpuset.sched_relax_domain_level
-rw-r--r-- 1 root root 0 Feb 18 14:07 notify_on_release
-rw-r--r-- 1 root root 0 Feb 18 14:07 tasks
devuser@product:/dev/cpuset/sys> 

E aqui está o mesmo diretório em uma máquina openSUSE 15.6:

devuser@product:/dev/cpuset/sys> ls -al
total 0
drwxr-xr-x 2 root root 0 Feb 18 11:25 .
dr-xr-xr-x 5 root root 0 Feb 18 11:25 ..
-rw-r--r-- 1 root root 0 Feb 18 11:29 cgroup.clone_children
-rw-r--r-- 1 root root 0 Feb 18 11:29 cgroup.procs
-rw-r--r-- 1 root root 0 Feb 18 11:29 cpu_exclusive
-rw-r--r-- 1 root root 0 Feb 18 11:29 cpus
-r--r--r-- 1 root root 0 Feb 18 11:29 effective_cpus
-r--r--r-- 1 root root 0 Feb 18 11:29 effective_mems
-rw-r--r-- 1 root root 0 Feb 18 11:29 mem_exclusive
-rw-r--r-- 1 root root 0 Feb 18 11:29 mem_hardwall
-rw-r--r-- 1 root root 0 Feb 18 11:29 memory_migrate
-r--r--r-- 1 root root 0 Feb 18 11:29 memory_pressure
-rw-r--r-- 1 root root 0 Feb 18 11:29 memory_spread_page
-rw-r--r-- 1 root root 0 Feb 18 11:29 memory_spread_slab
-rw-r--r-- 1 root root 0 Feb 18 11:29 mems
-rw-r--r-- 1 root root 0 Feb 18 11:29 notify_on_release
-rw-r--r-- 1 root root 0 Feb 18 11:29 sched_load_balance
-rw-r--r-- 1 root root 0 Feb 18 11:29 sched_relax_domain_level
-rw-r--r-- 1 root root 0 Feb 18 12:41 tasks
devuser@product:/dev/cpuset/sys> 

Então, exatamente o mesmo conjunto de arquivos, exceto que enquanto o Leap 15.5 tem um cpuset.prefixo em treze arquivos, o Leap 15.6 tem os mesmos arquivos, mas cpuset.removidos.

Editar: aqui está como eu fiz o diretório cpuset no sistema Leap 15.6. Em um sistema recém-reinicializado:

devuser@product:~> ls /dev/cpuset
ls: cannot access '/dev/cpuset': No such file or directory
devuser@product:~> sudo mkdir /dev/cpuset
[sudo] password for root: 
devuser@product:~> sudo mount -t cpuset none /dev/cpuset
devuser@product:~> sudo mkdir /dev/cpuset/sys
devuser@product:~> ls /dev/cpuset/sys
cgroup.clone_children  mem_exclusive       mems
cgroup.procs           mem_hardwall        notify_on_release
cpu_exclusive          memory_migrate      sched_load_balance
cpus                   memory_pressure     sched_relax_domain_level
effective_cpus         memory_spread_page  tasks
effective_mems         memory_spread_slab
devuser@product:~> 

Esta pergunta é uma continuação desta resposta . Em geral, meu objetivo é saber se meu sistema (Debian/Raspberry Pi 5 'bookworm') está atualizando meu relógio RTC/hardware a partir do horário do sistema. Observe que o RPi 5 (diferentemente de seus ancestrais Pi) tem um relógio RTC/hardware embutido .

Aqui está o que consegui determinar até agora:

1. Sinto que estabeleci que o relógio do sistema está sendo atualizado a partir do hwclock:

$ dmesg | grep "system clock" 

[    1.588793] rpi-rtc soc:rpi_rtc: setting system clock to 2025-02-18T04:59:13 UTC (1739854753)

Depois de alguma busca dmesg, no entanto, não consegui encontrar nenhuma indicação de que o hwclock esteja sendo atualizado a partir do horário do sistema. No entanto, encontrei uma referência a um fake-hardwarerelógio (o que parece estranho ). :

[    4.037230] systemd[1]: Starting fake-hwclock.service - Restore / save the current clock...

2. O kernel está aparentemente configurado para fazer atualizações de relógio em "ambas as direções":

$ cat /boot/config-$(uname -r) | grep -i HCTOSYS
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"  

$ cat /boot/config-$(uname -r) | grep -i SYSTOHC
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_SYSTOHC_DEVICE="rtc0"

Ocorreu-me que o kernel pode estar executando a sincronização SYSTOHC somente durante o desligamento, e talvez não esteja sendo capturado por dmesg... mas isso é um WAG.

Alguém pode explicar como confirmar se o kernel está (ou não) atualizando o hwclock/RTC?

Estou portando um dispositivo Linux embarcado para a linha principal de um kernel de fornecedor. Estou quase lá, mas há um problema do qual não consigo me livrar, que é a inicialização muito lenta do DRM.

Aqui está a configuração:
SOC: imx8mp
Kernel: 6.12
SO: Debian 12 bookworm

A GPU parece inicializar em um tempo razoável:

[    4.984644] etnaviv etnaviv: bound 38000000.gpu (ops gpu_ops [etnaviv])
[    5.005189] etnaviv etnaviv: bound 38008000.gpu (ops gpu_ops [etnaviv])
[    5.038057] etnaviv etnaviv: bound 38500000.npu (ops gpu_ops [etnaviv])
[    5.048542] etnaviv-gpu 38000000.gpu: model: GC7000, revision: 6204
[    5.060472] etnaviv-gpu 38008000.gpu: model: GC520, revision: 5341
[    5.087467] etnaviv-gpu 38500000.npu: model: GC8000, revision: 8002
[    5.101070] etnaviv-gpu 38500000.npu: etnaviv has been instantiated on a NPU, for which the UAPI is still experimental
[    5.121842] [drm] Initialized etnaviv 1.4.0 for etnaviv on minor 0

O systemd assume o controle em aproximadamente:

[    2.318927] systemd[1]: systemd 252.33-1~deb12u1 running in system mode (+PAM +AUDIT
+SELINUX +APPARMOR +IMA +SMACK +SECCOMP +GCRYPT -GNUTLS +OPENSSL +ACL +BLKID +CURL
+ELFUTILS +FIDO2 +IDN2 -IDN +IPTC +KMOD +LIBCRYPTSETUP +LIBFDISK +PCRE2 -PWQUALITY +P11KIT
+QRENCODE +TPM2 +BZIP2 +LZ4 +XZ +ZLIB +ZSTD -BPF_FRAMEWORK -XKBCOMMON +UTMP +SYSVINIT
default-hierarchy=unified)

Mas então há uma segunda rodada de inicialização de DRM que realmente habilita o fluxo de exibição:

[    6.904837] imx-dwmac 30bf0000.ethernet end0: Register MEM_TYPE_PAGE_POOL RxQ-0
[    6.971593] imx-dwmac 30bf0000.ethernet end0: PHY [stmmac-0:00] driver [SMSC LAN8710/LAN8720] (irq=147)
[    6.987060] imx-dwmac 30bf0000.ethernet end0: No Safety Features support found
[    6.994331] imx-dwmac 30bf0000.ethernet end0: IEEE 1588-2008 Advanced Timestamp supported
[    7.002765] imx-dwmac 30bf0000.ethernet end0: registered PTP clock
[    7.009583] imx-dwmac 30bf0000.ethernet end0: configuring for phy/rmii link mode
[    8.601862] imx-dwmac 30bf0000.ethernet end0: Link is Up - 100Mbps/Full - flow control rx/tx
[   15.334021] samsung-dsim 32e60000.dsi: supply vddcore not found, using dummy regulator
[   15.343694] samsung-dsim 32e60000.dsi: supply vddio not found, using dummy regulator
[   15.365379] samsung-dsim 32e60000.dsi: [drm:samsung_dsim_host_attach [samsung_dsim]] Attached sn65dsi83 device (lanes:4 bpp:24 mode-flags:0x2e3)
[   15.380621] [drm] Initialized imx-lcdif 1.0.0 for 32e80000.display-controller on minor 1
[   15.522131] Console: switching to colour frame buffer device 240x45
[   15.555056] imx-lcdif 32e80000.display-controller: [drm] fb0: imx-lcdifdrmfb frame buffer device
[   15.592315] dw100 32e30000.dwe: dw100 v4l2 m2m registered as /dev/video0
[   15.601817] hantro-vpu 38300000.video-codec: registered nxp,imx8mm-vpu-g1-dec as /dev/video1
[   15.611540] hantro-vpu 38310000.video-codec: registered nxp,imx8mq-vpu-g2-dec as /dev/video2

Há apenas um intervalo aleatório de 10 segundos entre essas duas rodadas de inicialização e não entendo o porquê.

systemd-analisar:

systemd-analyze
Startup finished in 2.034s (kernel) + 4.558s (userspace) = 6.592s 
graphical.target reached after 4.450s in userspace.

Agradecemos antecipadamente por qualquer ajuda!

Como os drivers oficiais NVIDIA 391.xx não suportam Linux 6.x, sou forçado a usar o noveau, mas o desempenho é muito ruim. Existe uma versão não oficial desses drivers para kernels Linux mais novos? Agradeço antecipadamente por sua resposta.