Editar: esta resposta está incorreta. Apesar de ainda ser uma possível causa para o oom-killer ser invocada, não é a causa neste caso específico.
Parece que isso ocorre devido à fragmentação da memória.
Da saída que você forneceu, o bloco de memória contígua de maior ordem que você tem é um bloco de 32kb na normal
zone. Isso significa que, se algo tentar alocar um pedaço de memória maior que 32kb, ele falhará.
Normalmente, isso não significa necessariamente que o oom-killer será invocado (caso contrário, um aplicativo pode solicitar um grande pedaço de memória e, assim, disparar o OOM), no entanto, esse é o kernel que está tentando alocar memória e, portanto, é um pouco mais sério. Neste caso exato, parece que a alocação foi acionada iniciando um novo processo, e o kernel estava tentando alocar memória para esse processo.
O kernel automaticamente tenta compactar (desfragmentar) a memória e obter pedaços maiores de memória contígua disponível, mas algumas páginas não podem ser movidas. E quanto mais tempo o sistema estiver em execução, mais dispersas serão as páginas "inamovíveis".
Então, basicamente, não há muito que você possa fazer. Realmente, a única opção é eliminar processos para liberar as páginas que não podem ser movidas.
Quanto ao que na saída acima indica a fragmentação de memória, são as seguintes linhas
DMA: 2358*4kB 912*8kB 25*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 17128kB
Normal: 4266*4kB 657*8kB 32*16kB 1*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB 0*8192kB 0*16384kB = 22864kB
Uma entrada como 32*16kb
significa que há 32 blocos contíguos de 16kb livres de memória.