A melhor maneira de criar um disco RAM no linux é o tmpfs. É um sistema de arquivos que vive em memória RAM, então não há necessidade de ext2. Você pode criar um tmpfs de tamanho de 16Gb com:
mount -o size=16G -t tmpfs none /mnt/tmpfs
Eu tenho uma máquina com 62GB de RAM e um tronco de apenas 7GB, então pensei em criar um disco de RAM e compilar lá. Eu não sou um especialista em Linux. Eu encontrei instruções na internet para criar o disco RAM:
mkfs -q /dev/ram1 8192
mas eu mudei o 8192 para o 16777216 em uma tentativa de alocar 16GB de disco RAM.
Eu recebi o seguinte erro:
mkfs.ext2: Filesystem larger than apparent device size.
Proceed anyway? (y,n)
Nesse ponto, eu me assustei e fui libertado.
sudo dmidecode --type 17 | grep Size
mostra
8x8192MB + 2048MB = 67584 MB
mas du on /dev dá 804K .
Esse é o problema? Posso superar esse /dev size?
A melhor maneira de criar um disco RAM no linux é o tmpfs. É um sistema de arquivos que vive em memória RAM, então não há necessidade de ext2. Você pode criar um tmpfs de tamanho de 16Gb com:
mount -o size=16G -t tmpfs none /mnt/tmpfs
O Linux é muito eficiente no uso da RAM. Não é de surpreender que você veja pouca ou nenhuma aceleração com tmpfs . As maiores peças a serem lidas na memória (e, portanto, capazes de retardar o processo) são as ferramentas (compilador, assembler, linker), e em um make serão carregadas na memória na inicialização e nunca a deixarão. O que resta é a leitura na fonte (a gravação dos resultados não irá atrasá-lo, a menos que a memória seja severamente restringida). Mais uma vez, os arquivos de cabeçalho do comon ficarão por perto, somente a fonte do usuário exigirá leitura. E é improvável que seja mais do que alguns megabytes. Criar um disco RAM grande (ou mesmo muito uso de tmpfs ) pode muito bem desacelerar as coisas (tornando restrita a memória de compilação, os arquivos no RAMdisk ou em tmpfs não podem ser usados diretamente de lá).
O problema é que o tamanho máximo de um disco virtual, mais especificamente do tamanho da memória que pode ser acessado pelo driver ramdisk é configurado em tempo de compilação, pode ser substituído no momento da inicialização, mas permanece fixo quando o kernel é carregado na memória. O valor padrão é provavelmente medido em megabytes. Se bem me lembro, a memória de um ramdisk é reservada quando o driver é carregado, todos os ramdisks são do mesmo tamanho e existem 16 ramdisks por padrão. Então nem você quer um tamanho de disco ram de 16G: -)
Como afirmado na outra resposta, o tmpfs é o que você deseja usar. Além disso, você não ganhará muito tendo todo o seu SO em um ramdisk / tmpfs. Apenas copie seu builddir para um tmpfs e faça sua compilação então. Você pode ter que garantir que todos os resultados temporários sejam gravados em um local que esteja no tmpfs também.
Para criar um disco de RAM grande após a inicialização, sem mexer nos parâmetros do kernel, isso parece funcionar. Use tmpfs, crie um arquivo, monte-o via loop e monte-o através de um sistema de arquivos:
mount -t tmpfs -o size=200M tmpfs temp/
cd temp/
dd if=/dev/zero of=disk.img bs=1M count=199
losetup /dev/loop0 disk.img
mkfs.ext4 /dev/loop0
mount /dev/loop0 temp2/
Provavelmente um pouco de penalidade de desempenho passando por várias camadas diferentes ... mas pelo menos funciona.
OP a quantidade de RAM é expressa em MB. Então tudo que você precisa para entrar lá é 16384. E então voila você estaria no negócio.
Você pode montar um sistema de arquivos ramfs , copiar seu projeto para ele e trabalhar a partir daí. Isso garante que seus arquivos de entrada sejam carregados na RAM e não serão lidos novamente da unidade de disco mais lenta. No entanto, como você descobriu, isso geralmente não é uma estratégia útil. Você já tem exatamente o mesmo benefício.
Ramfs is a very simple filesystem that exports Linux's disk caching mechanisms (the page cache and dentry cache) as a dynamically resizable RAM-based filesystem.
- link
Você já pode confiar que seus arquivos de entrada são armazenados em cache na RAM, na primeira vez que são lidos. Seus arquivos de saída também são armazenados em cache, para que você não espere que eles sejam gravados no disco.
Não há limite artificial de quanto você pode armazenar em cache, por quanto tempo ele permanece em cache, etc. Os caches só começam a ser descartados depois que você preencheu a RAM. Qual cache é descartado primeiro é escolhido por algoritmos terrivelmente elaborados. A primeira aproximação é descrevê-la como menos recentemente usada. Veja Qual página Algoritmos de substituição são usados no kernel Linux para cache de arquivos OS?
Observe que seu editor de texto explicitamente fsync() salvou arquivos em disco.
Se você executar testes de um programa que envolva fsync() , executá-los em um sistema de arquivos como ramfs poderá acelerá-los. Outra estratégia é tentar desabilitar fsync() com eatmydata / nosync.so .
Alguns outros sistemas operacionais podem ter limitações específicas, que podem ser ignoradas usando um ramdisk. De um lado, a falta de qualquer caching de arquivos é o motivo pelo qual os ramdisks eram populares em DOS .
tmpfs funciona da mesma forma que ramfs , exceto pelo fato de poder usar o espaço de troca se você tiver um. Ou seja se você precisar de RAM para outra coisa, os algoritmos Menos Recentemente Usados podem selecionar blocos de dados de tmpfs e trocá-los para o disco.
A maioria das pessoas fica com tmpfs , porque também permite limitar o tamanho total e mostra o espaço usado corretamente. no comando df . Não sei por que essa diferença existe. O limite de tamanho em tmpfs protege você de encher acidentalmente toda a sua RAM e basicamente matar seu sistema. O padrão é metade da sua memória RAM.
O acima é uma simplificação adaptada ao seu caso. As gravações em arquivos no seu caso não precisam aguardar o disco. No entanto, existem alguns casos de escrita que fazem. Veja a excelente postagem no blog Por que as gravações em buffer às vezes são interrompidas . O caso mais surpreendente é uma mudança recente no Linux chamada de "gravações de páginas estáveis".