Eu sei que quando uma página de cache de página é modificada, ela é marcada como suja e requer um write-back, mas o que acontece quando:
Cenário: O arquivo /apps/EXE, que é um arquivo executável, é paginado completamente no cache da página (todas suas páginas estão em cache/memória) e sendo executado pelo processo P
A liberação contínua substitui /apps/EXE por um novo executável.
Suposição 1: suponho que o processo P (e qualquer outra pessoa com um descritor de arquivo referenciando o executável antigo) continuará usando o antigo, na memória /apps/EXE sem problemas, e qualquer novo processo que tentar executar esse caminho obterá o novo executável.
Suposição 2: Presumo que, se nem todas as páginas do arquivo forem mapeadas na memória, tudo ficará bem até que haja uma falha de página exigindo páginas do arquivo que foram substituídas e provavelmente ocorrerá uma falha de segmentação?
Pergunta 1: Se você bloquear todas as páginas do arquivo com algo como vmtouch, isso altera o cenário?
Pergunta 2: Se /apps/EXE estiver em um NFS remoto, isso faria alguma diferença? (presumo que não)
Por favor, corrija ou valide minhas 2 suposições e responda minhas 2 perguntas.
Vamos supor que esta é uma caixa CentOS 7.6 com algum tipo de kernel 3.10.0-957.el7
Atualização: Pensando mais sobre isso, gostaria de saber se esse cenário não é diferente de qualquer outro cenário de página suja.
Suponho que o processo que escreve o novo binário fará uma leitura e obterá todas as páginas de cache, pois todas as páginas serão paginadas e, em seguida, todas essas páginas serão marcadas como sujas. Se eles estiverem bloqueados, eles serão apenas páginas inúteis ocupando a memória central depois que a contagem de referências chegar a zero.
Eu suspeito que quando os programas atualmente em execução terminarem, qualquer outra coisa usará o novo binário. Supondo que tudo esteja correto, acho que só é interessante quando apenas parte do arquivo é paginado.
