Pergunta

Eu estou usando ARM926EJS. Estou recebendo 20% a mais de velocidade de memória no teste de cópia de memória, sem Linux (apenas como um executável Introdução). Mas, em linux mesmo código está sendo executado 20% mais lento.

código é

 
/// Below code just performs burst mode memcopy test.        
void asmcpy(void *a, void *b, int iSize)
{
   do
  {
    asm volatile (
             "ldmia %0!, {r3-r10} \n\t"
             "stmia %0!, {r3-r10} \n\t"
             :"+r"(a), "+r"(b)
             :
             :"r"(r3),"r"(r4),"r"(r5),"r"(r6),"r"(r7),"r"(r8),"r"(r9),"r"(r10)
             );
  }while(size--)
}

Eu verifiquei que nenhum outro processo está tomando tempo de CPU no linux. (Eu chequei isso com o uso de comando tempo, mostra em tempo real é o mesmo que tempo usr )

Por favor me diga o que pode ser o problema com o Linux?

Obrigado e cumprimentos.

ADICIONADO:

meu código de teste é

int main()
{
  int a[320 * 120], b[320 * 120];

 for(int i=0; i != 10000; i++)
 {
   /// Size is divided by 8 because our memcpy function performs 8 integer load stores in the iteration
   asmcpy(a, b, (320 * 120) / 8);
 }
}

Obter executável Iniciado é um arquivo bin que é enviado para a memória RAM usando porta serial e executa diretamente por saltar para esse endereço na RAM. (Sem a necessidade de um sistema operacional)

ADICIONADO.

Eu não vi tal diferença de desempenho em outro processors.They estavam usando RAM SD, Este processador está usando DDR Ram. ele pode ser um motivo?

ADICIONADO. Cache de dados não está habilitado a começar código e cache de dados é eabled no modo Linux, portanto o ideal seria todos os dados devem ser armazenados em cache e se acessada sem qualquer latência RAM, Mas ainda assim Linux é de 20% lento.

ADICIONADO: Meu microcontrolador é LPC3250. Tanto o teste estão sendo testados em mesma RAM DDR externa.

Foi útil?

Solução

Este chip tem uma MMU, por isso Linux é provável usá-lo para gerenciar a memória. Talvez apenas permitindo que introduz algumas acerto de desempenho. Além disso, o Linux utiliza uma estratégia de alocação de memória preguiçoso, apenas a atribuição de páginas de memória para um processo quando ele primeiro atinge. Se você está copiando um grande pedaço de memória, o MMU irá gerar falhas de página para pedir ao kernel para alocar uma página enquanto dentro de seu loop. Em um processador low-end, todas essas mudanças de contexto liberações do cache de causa e introduzir uma desaceleração perceptível.

Se o seu sistema é pequeno o suficiente, tente uma versão MMU-less do Linux (como uClinux ). Talvez fosse deixar você usar um chip mais barato com desempenho semelhante. Em sistemas embarcados, cada centavo conta.

atualização: Alguns detalhes adicionais:

processo Cada Linux recebe o seu próprio mapeamentos de memória, No início, este incluir apenas o kernel e (talvez) de código executável. Todo o resto da 4GB linear (em 32 bits) parece disponível, mas não há páginas de RAM atribuídos a eles. Assim que você ler ou escrever um endereço de memória não alocado, o MMU sinaliza uma falha de página e muda para o kernel. O kernel vê que ele ainda tem muitas páginas RAM livre, então pega um, atribui-lo para o ponto em falha e retorna ao seu código, que termina a instrução interrompida. O muito próximo não irá falhar porque a página inteira (normalmente 4KB) já está atribuído; mas alguns iterações mais tarde, ele vai bater um outro espaço não atribuído, ea MMU irá chamar o kernel novamente.

Outras dicas

Como você está realizando o momento? Não há nenhum código de tempo no seu exemplo.

Você tem certeza que você não está medindo / tempo de carregamento O processo de descarregamento?

É a velocidade do clock do processador a mesma em ambos os casos?

Se estiver usando SDRAM externa são os horários de RAM o mesmo em ambos os casos?

É o cache de dados habilitado em ambos os casos?

Clifford

Começar não é "apenas um executável". Deve haver algum código para definir o registo controlador de DDR.

Se o cache também é habilitado, então que assim deve ser o MMU. Eu acho que em ARM926EJS, você não pode ter cache de dados sem MMU.

Eu acredito que a cada mudança de contexto resulta em um flush cache, porque o cache é praticamente indexado, praticamente marcados e Kernel e Userspace não compartilham o mesmo espaço de endereço, então você provavelmente tem esvaziamento de cache muito mais indesejado no que sem OS.

Aqui é um papel com algum aspecto na custo de VIVT flush cache quando rodando Linux

O microcontrolador (não apenas o ARM CPU) que você está usando?

É possível que na não-Linux executar a matriz que você está testando é RAM no próprio dispositivo microcontrolador enquanto no teste de Linux a matriz que está sendo testado é na RAM externa? RAM interna geralmente é acessada muito mais rápido do que a RAM externa -. A sua conta pode para o teste de Linux ser mais lento, mesmo se o cache de dados é habilitado somente para o funcionamento Linux

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top