Faz ou força o tmpfs a trocar antes do cache de arquivos

Question

Considere o seguinte cenário. Você tem uma mídia somente leitura lenta (por exemplo, Thumb Drive protegido contra gravação, CD / DVD, qualquer) em que você instalou o Linux (e não um Live CD em si, mas uma compilação normal) e em um computador com literalmente nenhuma outra forma de armazenamento. É lento, porque é USB 2. O sistema de arquivos raiz é montado como overlayfs para que seja "gravável" para logs e muitos outros trabalhos temporários que você faz, mas todas as gravações vão para a RAM (tmpfs upperdir). Cenário bastante típico para uma situação de distro ao vivo.

Como não há outras formas de armazenamento, o swap é montado no zram. Então, quando o Linux decide trocar, ele compacta essas páginas e as armazena na RAM, mas pelo menos elas são compactadas. Isso é realmente decente, uma vez que a RAM da maioria dos aplicativos é facilmente compressível (a RAM é geralmente muito redundante nos dados, já que se destina a ser "rápida"). Isso funciona bem para a memória do aplicativo, mas não para o tmpfs.

Aqui está a coisa: zram é rápido , incrivelmente. O Thumb Drive, por outro lado, é lento. Vamos dizer que é 20 MiB / s, o que é muito lento em comparação. Você pode ver o problema e porque o kernel não fará a coisa certa aqui.

Note que esta questão é não uma duplicação de Como fazer arquivos dentro do TMPFS mais propensos a trocar . A questão é praticamente a mesma, mas não estou satisfeito com essa resposta nessa pergunta, desculpe. O kernel definitivamente faz não fazer a "coisa certa" por si só, independentemente de quão inteligente as pessoas estão projetando. Eu não gosto quando as pessoas não entendem a situação e acham que sabem melhor. Eles atendem ao caso médio. É por isso que o Linux é tão atraente, porque, por mais inteligente que seja, não pode prever para que será usado.

Por exemplo, eu posso (e fiz) definir vm.swappiness (/ proc / sys / vm / swappiness) para 100, que diz para trocar a memória do aplicativo de forma agressiva e manter o cache de arquivos. Essa opção é legal, mas não é tudo, infelizmente.

Eu quero priorizar manter o cache de arquivos sobre qualquer outro uso de RAM ao lidar com swap. Isso porque descartar o cache de arquivos faz com que ele tenha que ler a partir da unidade lenta de 20 MiB / s, que é muito muito mais lenta do que a troca para o zram. Para aplicativos, o vm.swappiness funciona, mas não para tmpfs.

tmpfs é montado como cache de páginas, portanto, ele tem a mesma prioridade que o cache de arquivos. Se você ler um arquivo do tmpfs, ele será priorizado sobre uma entrada de cache de arquivo mais antiga (usada mais recentemente). Mas isso é ruim, o kernel claramente não faz a coisa certa aqui. Deve-se considerar que a troca de tmpfs para zram é muito melhor, mesmo que seja "usada mais recentemente" do que o cache de arquivos, porque a leitura da unidade é muito lenta.

Portanto, preciso explicitamente dizer a ele para trocar de tmpfs com mais frequência em comparação com o cache de arquivos: que ele deve preservar o cache de arquivos mais do que tmpfs. Existem tantas opções em / proc / sys / vm mas nada que eu possa encontrar. Decepcionante, na verdade.

Falhando nisso, existe uma maneira de dizer ao kernel que alguns dispositivos / drives são apenas muito mais lentos do que outros, e deve preferir manter o cache para eles mais do que outros? tmpfs e zram são rápidos. O pen drive não é. Posso contar ao kernel esta informação?

Não pode fazer "a coisa certa" por si só se tratar todos os drives da mesma forma. É muito mais rápido trocar o tmpfs por um disco rápido como o zram do que por deixar os caches em uma unidade lenta, mesmo se o tmpfs for usado mais recentemente.

Quando ele ficar sem memória livre, ele começará a trocar a memória do aplicativo (good) devido a swappiness ou a deixar os caches de arquivos antigos (ruins). Se eu acabar lendo de novo esses arquivos, será muito lento. Muito mais lento do que se decidisse trocar alguns tmpfs, mesmo que fossem usados recentemente, e depois ler de novo. Porque o zram é uma ordem de grandeza mais rápida.

    

Answer 1

Eu ficaria bastante confiante de que aumentar o swappiness torna o kernel menos disposto a trocar páginas tmpfs, e mais disposto a despejar páginas em cache de outros sistemas de arquivos que não sejam suportados por swap. Veja commit 4f98a2fee8ac "vmscan: listas LRU divididas em conjuntos de arquivos anon &":

Split the LRU lists in two, one set for pages that are backed by real file systems ("file") and one for pages that are backed by memory and swap ("anon"). The latter includes tmpfs.

e

link

 * Determine how aggressively the anon and file LRU lists should be
 * scanned.  The relative value of each set of LRU lists is determined
 * by looking at the fraction of the pages scanned we did rotate back
 * onto the active list instead of evict.
 *
 * nr[0] = anon inactive pages to scan; nr[1] = anon active pages to scan
 * nr[2] = file inactive pages to scan; nr[3] = file active pages to scan
 */
static void get_scan_count(struct lruvec *lruvec, struct mem_cgroup *memcg,
               struct scan_control *sc, unsigned long *nr,
               unsigned long *lru_pages)
{
    int swappiness = mem_cgroup_swappiness(memcg);

...

    /* If we have no swap space, do not bother scanning anon pages. */
    if (!sc->may_swap || mem_cgroup_get_nr_swap_pages(memcg) <= 0) {
        scan_balance = SCAN_FILE;
        goto out;
    }

...

For example, I can (and did) set vm.swappiness (/proc/sys/vm/swappiness) to 100

Você não diz explicitamente se conseguiu quantificar isso como não fazendo diferença para o resultado desejado. Dito isto, dada a extrema diferença de velocidade, acho que você realmente quer um valor maior de swappiness:

Reconsiderando a troca , LWN.net, 7 de junho de 2016

The first step in the patch set is to widen the range of possible settings for the swappiness knob. In current kernels, it can go from zero (no swapping at all if possible) to 100 (reclaim anonymous and file-backed pages equally). Johannes raises the maximum to 200; at that value, the system will strongly favor swapping. That is a possibility nobody has ever wanted before, but fast drives have now made it useful.

...

Memory-management changes are fraught with potential hazards, though, and it is entirely possible that other workloads will be hurt by these changes. The only way to gain confidence that this won't happen is wider testing and review. This patch set is quite young; there have been some favorable reviews, but that testing has not yet happened. Thus, it may be a while before this code goes anywhere near a mainline kernel.

O

zram é certamente um exemplo de um disco rápido. É explicitamente mencionado na discussão deste patch.

Infelizmente, não encontrei nenhum commit deste patch nem uma v2 desta série de patches.

O efeito exato do swappiness também é discutido em mais detalhes. Eu não descobri como isso combina com a explicação mais antiga do LWN.net sobre detalhes de swappage aqui .