Como o kernel decide entre cache de disco e swap?

O nome dado à tarefa geral de liberar páginas físicas de memória é recuperação e abrange várias tarefas. A recuperação é principalmente impulsionada por alocações de página, com vários níveis de urgência. Em um sistema descarregado, as alocações de página podem ser satisfeitas sem esforço e não acionam nenhuma recuperação. Em sistemas carregados moderadamente, as alocações de página ainda podem ser satisfeitas imediatamente, mas também farão kswapdcom que sejam despertadas para executar a recuperação de segundo plano. Em sistemas carregados em que as alocações de página não podem mais ser atendidas imediatamente, a recuperação é executada de forma síncrona.

Páginas recuperáveis ​​são páginas que armazenam conteúdo que pode ser encontrado ou disponibilizado em outro lugar. É aqui que entra em jogo o típico ato de equilíbrio: memória cujo conteúdo também está em arquivos (ou deveria terminar em arquivos), v. memória cujo conteúdo não está (e precisa ser trocado). As primeiras são armazenadas no cache de página, as últimas não, razão pela qual as explicações de balanceamento geralmente falam sobre cache de página vs. swap.

A decisão de favorecer um sobre o outro é determinada em um único local no kernel, get_scan_count, controlado pelas configurações em struct scan_control. A finalidade desta função é descrita a seguir:

Determine com que agressividade as listas de LRU de arquivo e anon devem ser verificadas. O valor relativo de cada conjunto de listas LRU é determinado observando a fração das páginas digitalizadas que giramos de volta para a lista ativa em vez de despejar.

Talvez surpreendentemente para uma função chamada get_..., isso não usa um valor de retorno; em vez disso, ele preenche a matriz apontada pelo unsigned long *nrponteiro, com quatro entradas correspondentes a páginas inativas anônimas (páginas sem suporte, não usadas recentemente), páginas ativas anônimas (páginas sem suporte, usadas recentemente), arquivo inativo páginas (páginas não usadas recentemente no cache de página) e páginas ativas de arquivo (páginas usadas recentemente no cache de página).

get_scan_countcomeça recuperando o valor de “swappiness” apropriado, de mem_cgroup_swappiness. Se o cgroup de memória atual for um cgroup v1 não-root habilitado, sua configuração de swappiness é usada; caso contrário, é o infame /proc/sys/vm/swappiness. Ambas as configurações compartilham o mesmo propósito ; eles dizem ao kernel

o custo de IO relativo de trazer de volta uma página anônima trocada versus recarregar uma página do sistema de arquivos

Antes de realmente usar esse valor, get_scan_countdetermina a estratégia geral que deve ser aplicada:

• se não houver troca, ou páginas anônimas não puderem ser recuperadas no contexto atual, ele irá atrás apenas de páginas com suporte de arquivo;
• se o cgroup de memória desabilita totalmente a troca, ele irá somente após as páginas com suporte de arquivo;
• se o swappiness não estiver desabilitado (definido como 0) e o sistema estiver quase sem memória, ele seguirá todas as páginas igualmente;
• se o sistema estiver quase sem páginas de arquivo, ele irá atrás apenas de páginas anônimas;
• se houver cache de página inativa suficiente, ele irá atrás apenas de páginas com backup de arquivo;
• em todos os outros casos, ajusta o “peso” dado às várias LRUs dependendo do custo de I/O correspondente.

Depois de determinar a estratégia, ele itera sobre todas as LRUs elimináveis ​​(anônimas inativas, anônimas ativas, apoiadas por arquivos inativos, apoiadas por arquivos ativos, nessa ordem) para determinar quantas páginas de cada uma devem ser verificadas; Vou ignorar v1 cgroups:

• se a estratégia for “ir atrás de todas as páginas igualmente”, todas as páginas em todas as LRUs são passíveis de serem digitalizadas, até o tamanho determinado pelo fator scan_controlde deslocamento de ;priority
• se a estratégia for “ir atrás somente de páginas com suporte de arquivo” ou “ir atrás somente de páginas anônimas”, todas as páginas nas LRUs correspondentes são candidatas (novamente, deslocadas por priority), nenhuma nas outras LRUs;
• caso contrário, os valores são ajustados de acordo com a swappiness.

A varredura de página real é conduzida por shrink_lruvec, que usa os comprimentos de varredura determinados acima e reduz repetidamente as LRUs até que os destinos sejam alcançados (ajustando os destinos à medida que avança de várias maneiras). Feito isso, as LRUs ativas/inativas são reequilibradas.

Voltando às suas perguntas:

• o cache de página e os arquivos mapeados na memória são tratados igualmente;
• a recuperação de página não se baseia puramente no último acesso (não expliquei como as LRUs são usadas ou como funciona o rebalanceamento; leia o capítulo correspondente em Entendendo o Gerenciador de Memória Virtual Linux de Mel Gorman para obter detalhes);
• o kernel não os usa igualmente; eles são priorizados de forma diferente com base nas circunstâncias e podem ser configurados por meio de vários controles ( swappiness, cgroups, limites de marca d'água baixos...).

A prioridade de troca só determina para onde uma página vai depois que for decidido trocá-la. (Aliás, a swappinessdocumentação e as explicações acima devem deixar claro que não há granularidade suficiente no custo de E/S para lidar bem com configurações mistas de troca de ZRAM/disco...)

Há muito mais para explicar, incluindo como scan_controlé configurado, mas suspeito que isso já seja muito longo! Se você deseja rastrear o custo de recuperação, pode vê-lo na contabilidade de atraso de tarefa (consulte também struct taskstats).