EDIT1 After stopping systemd-logind - which native Xorg responds to by dying - and restarting Xorg, I see the entire 6GB of swap wiped out.
Após a segunda vez, posso confirmar que isso é um bug no systemd-logind. logind se lembra de fechar a cópia do DRM fd que ele contém, mas não consegue fechar a cópia que é mantida em PID1 (usado o suporte "reinicialização contínua" do logind):
$ sudo lsof /dev/dri/card0 | grep systemd
[sudo] password for alan-sysop:
lsof: WARNING: can't stat() fuse.gvfsd-fuse file system /run/user/1000/gvfs
Output information may be incomplete.
systemd 1 root 16u CHR 226,0 0t0 14690 /dev/dri/card0
systemd 1 root 87u CHR 226,0 0t0 14690 /dev/dri/card0
systemd 1 root 101u CHR 226,0 0t0 14690 /dev/dri/card0
systemd 1 root 106u CHR 226,0 0t0 14690 /dev/dri/card0
systemd 1 root 110u CHR 226,0 0t0 14690 /dev/dri/card0
systemd-l 860 root 21u CHR 226,0 0t0 14690 /dev/dri/card0
systemd-l 860 root 25u CHR 226,0 0t0 14690 /dev/dri/card0
Isso parece muito com um bug conhecido, que já deve estar corrigido na v238 do systemd .
De fato, o logind parece estar vazando um DRM fd dessa forma toda vez que eu entro e saio do GNOME. Presumivelmente, esse bug só se torna óbvio quando você tem servidores de exibição desligados impuros, para que eles não tenham a chance de desalocar os buffers anexados ao seu DRM fd.
EDIT2: Am I right to guess that a file descriptor of a graphics device (DRM), can hold a reference to swappable memory? Note logind holds such file descriptors.
Resposta: sim.
filp
SHMEM file node used as backing storage for swappable buffer objects.
- link
Pelo que entendi, "nó do arquivo SHMEM" aqui é algo que faz exatamente o mesmo trabalho que um arquivo tmpfs / memfd. A citação acima é referente a um "objeto buffer GEM" ...
The mmap system call can't be used directly to map GEM objects, as they don't have their own file handle. Two alternative methods currently co-exist to map GEM objects to userspace... The second method uses the mmap system call on the DRM file handle.
- link
CONCLUSÃO: alguém deve realmente checar novamente o código atual no logind no que se refere ao fechamento de identificadores de arquivo:).
Apêndice: como você pode tentar descartar memfds
Does anyone have a nice way to check memory usage of memfds?
O uso de memória dos memfds pode ser lido usando stat --dereference ou du -D no link simbólico mágico em /proc/$PID . Em fd/$FD para um descritor de arquivo ou - que você esqueceu - map_files/... para objetos mapeados pela memória.
Eu não tenho uma conveniência muito boa para isso, mas você pode pelo menos procurar os FDs individuais mais maciços ou arquivos mapeados. (O exemplo abaixo não é uma evidência adicional; foi tirado depois que os 6GB de uso de troca foram embora).
$ sudo du -aLh /proc/*/map_files/ /proc/*/fd/ | sort -h | tail -n 10
du: cannot access '/proc/self/fd/3': No such file or directory
du: cannot access '/proc/thread-self/fd/3': No such file or directory
108M /proc/10397/map_files/7f1e141b4000-7f1e1ad84000
111M /proc/14862/map_files/
112M /proc/10397/map_files/
113M /proc/18324/map_files/7efdda2fb000-7efddaafb000
121M /proc/18324/map_files/7efdea2fb000-7efdeaafb000
129M /proc/18324/map_files/7efdc82fb000-7efdc8afb000
129M /proc/18324/map_files/7efdd42fb000-7efdd4afb000
129M /proc/18324/map_files/7efde52fb000-7efde5afb000
221M /proc/26350/map_files/
3.9G /proc/18324/map_files/
$ ps -x -q 18324
PID TTY STAT TIME COMMAND
18324 pts/1 S+ 0:00 journalctl -b -f
$ ps -x -q 26350
PID TTY STAT TIME COMMAND
26350 ? Sl 4:35 /usr/lib64/firefox/firefox
$ sudo ls -l /proc/18324/map_files/7efde52fb000-7efde5afb000
lr--------. 1 root root 64 Mar 19 00:32 /proc/18324/map_files/7efde52fb000-7efde5afb000
-> /var/log/journal/f211872a957d411a9315fd911006ef03/user-1001@c3f024d4b01f4531b9b69e0876e42af8-00000000002e2acf-00055bbea4d9059d.journal