Pregunta

Estoy usando ARM926EJS. Estoy obteniendo un 20% más de velocidad de memoria en la prueba de copia de memoria, sin Linux (solo como un ejecutable de introducción). Pero en Linux, el mismo código se ejecuta un 20% más lento.

El código es

 
/// 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--)
}

Verifiqué que ningún otro proceso está tomando el tiempo de CPU en linux. (Lo verifiqué con el comando de uso del tiempo, muestra que tiempo real es igual que tiempo de usuario )

Por favor, dime cuál puede ser el problema con Linux?

Gracias & amp; Saludos.

AÑADIDO:

mi código de prueba es

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);
 }
}

El ejecutable de Getting Started es un archivo bin que se envía a la RAM utilizando el puerto serie y se ejecuta directamente al saltar a esa dirección en la RAM. (sin la necesidad de un sistema operativo)

AÑADIDO.

No he visto tal diferencia de rendimiento en otros procesadores. Estaban usando SD RAM. Este procesador está usando DDR Ram. ¿Puede ser una razón?

AÑADIDO.   La memoria caché de datos no está habilitada para comenzar el código y la memoria caché de datos está habilitada en el modo Linux, por lo que lo ideal es que todos los datos se almacenen en caché y se pueda acceder a ellos sin latencia de RAM, pero aún así, Linux es un 20% lento.

AÑADIDO:   Mi microcontrolador es LPC3250. Ambas pruebas se han probado en la misma memoria RAM DDR externa.

¿Fue útil?

Solución

Este chip tiene una MMU, por lo que es probable que Linux lo use para administrar la memoria. Tal vez solo habilitarlo introduce algún impacto de rendimiento. Además, Linux utiliza una estrategia de asignación de memoria perezosa, y solo asigna páginas de memoria a un proceso cuando lo alcanza por primera vez. Si está copiando una gran parte de la memoria, la MMU generará fallas en la página para pedirle al núcleo que asigne una página dentro de su bucle. En un procesador de gama baja, todos estos cambios de contexto provocan vacíos en la memoria caché e introducen una desaceleración notable.

Si su sistema es lo suficientemente pequeño, pruebe una versión de Linux sin MMU (como uClinux ). Tal vez le permitiría usar un chip más barato con un rendimiento similar. En los sistemas integrados, cada centavo cuenta.

actualización: Algunos detalles adicionales:

Cada proceso de Linux obtiene sus propias asignaciones de memoria. Al principio, esto incluye solo el kernel y (tal vez) el código ejecutable. Todo el resto de los 4GB lineales (en 32 bits) parece estar disponible, pero no hay páginas RAM asignadas. Tan pronto como usted lee o escribe una dirección de memoria no asignada, la MMU señala un fallo de página y cambia al núcleo. El kernel ve que todavía tiene muchas páginas RAM libres, por lo que elige una, la asigna al punto de falla y regresa a su código, que termina la instrucción interrumpida. La siguiente no fallará porque ya se asignó la página completa (normalmente 4 KB); pero unas pocas iteraciones más tarde, llegará a otro espacio no asignado, y la MMU invocará el núcleo nuevamente.

Otros consejos

¿Cómo estás realizando el tiempo? No hay código de tiempo en su ejemplo.

¿Está seguro de que no está midiendo el tiempo de carga / descarga del proceso?

¿La velocidad de reloj del procesador es la misma en ambos casos?

¿Si los SDRAM externos son los tiempos de RAM iguales en ambos casos?

¿Está habilitada la caché de datos en ambos casos?

Clifford

Comenzar no es " solo un archivo ejecutable " ;. Debe haber algún código para establecer el registro del controlador DDR.

Si el caché también está habilitado, entonces debe ser la MMU. Creo que en ARM926EJS, no puede tener caché de datos sin MMU.

Creo que cada cambio de contexto da como resultado un vaciado de caché, porque el caché está prácticamente indexado, virtualmente etiquetado y Kernel y Userspace no comparten el mismo espacio de direcciones, por lo que probablemente tenga mucho más vaciado de caché no deseado en el que sin OS.

Aquí hay un documento con algún aspecto en el costo de vaciar la memoria caché VIVT al ejecutar Linux

¿Qué microcontrolador (no solo qué CPU ARM) está usando?

¿Es posible que en la ejecución no Linux la matriz que está probando sea la RAM en el dispositivo del microcontrolador mientras que en la prueba de Linux la matriz que se está probando esté en la RAM externa? Por lo general, se accede a la RAM interna mucho más rápido que la RAM externa; esto podría explicar que la prueba de Linux sea más lenta, incluso si el almacenamiento en caché de datos está habilitado solo para la ejecución de Linux.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top