em relação ao comportamento da memória compartilhada

Question

Percebendo um comportamento estranho de desempenho ao usar memória compartilhada que é suportada por arquivo (ou seja, abrir arquivo definido pelo usuário e mmap () o mesmo no espaço do processo). Ao fazer um memcpy () na seção de memória compartilhada, às vezes um atraso é observado na ordem de milissegundos. Para ser específico, em cenários normais 2048 bytes são copiados em 0,4, mas às vezes o mesmo número de bytes leva cerca de 10 a 20 milésimos de segundo para copiar. Isso acontece aleatoriamente a qualquer momento. O próximo quadro de dados de 2048 retorna ao horário normal.

A versão do kernel é 2.6.27.23-0.1.

Aprecie qualquer pista de alguém, sobre o que está acontecendo e porque o atraso é visto. Eu até tentei usando shm_open () e depois mmap (), sem diferença

As chamadas mmap são assim:

int fd = ::open("somefile", flags, 0666);
if(fd != -1) {
  myBasePointer = ::mmap(0, sizeInBytes,
                         PROT_READ|PROT_WRITE, MAP_SHARED,
                         fd, offsetInBytes);
} 

Um processo cria o arquivo e mmap s, os outros processos abrem o arquivo e mmap s no seu espaço de endereçamento. O arquivo é um arquivo normal em um sistema de arquivos comum.

    

Answer 1

Idéia 1: Tente adicionar o MAP_LOCKED na sua chamada mmap, para garantir que as páginas permaneçam respaldadas por RAM real o tempo todo. Mesmo que você tenha muita RAM, ainda é possível que a parte que você precisa esteja sendo paginada por algum motivo. Como você parece ser sensível à latência, é recomendável especificar esse sinalizador, independentemente da quantidade de RAM livre em seu hardware atual.

Idéia 2: Especifique também MAP_POPULATE para garantir que as entradas da tabela de páginas sejam criadas no momento do mmap e não no tempo da falha. Embora a AFAIK, isso causaria apenas latência na falha da primeira página, e não nas falhas subseqüentes. Mas novamente uma boa prática defensiva.

Idéia 3: Usar um mapeamento compartilhado anônimo (em oposição a um arquivo real), eliminando assim o sistema de arquivos, faz com que a latência desapareça? Se isso ajudar, você sempre poderá gravar o conteúdo da região compartilhada anônima em um arquivo (talvez com uma frequência menor) de um encadeamento auxiliar.

Idéia 4: Simplesmente tente com um kernel mais novo. O kernel do Linux mudou muito desde que você fez sua pergunta.

Finalmente, como você está medindo a latência do memcpy? Você está confiante de que não está:

• Incluindo um grande atraso devido à obtenção da hora atual? Por exemplo, latência syscall, se você estiver chamando um syscall; nem
• Incluindo saltos de clock causados por correções de NTP; nem
• Incluindo latência de bloqueio (um memcpy de 2k não é atômico); nem
• Usando um método de medição de tempo cuja precisão excede sua precisão?