2011-11-23 14 views
6

¿Qué tan grande es (aproximadamente) una sobrecarga de syscall de E/S en Linux desde el programa C, me refiero a qué tan grave se está ejecutando, p. ¿muchas operaciones pequeñas de read/write comparadas con read/write en memorias intermedias grandes (en archivos regulares o sockets de red)? La aplicación es fuertemente multiproceso.Sobrecarga de Syscall

+5

Es 20% malo. ¿Cuál es su métrica de rendimiento? –

+1

La E/S suele ser una de las partes, si no la más lenta, de un programa. –

+0

@GregHewgill, para el rendimiento general, la mayoría de las personas usa el tiempo. P.ej. es 2ms malo. Supongo que hay un debate existencial sobre la naturaleza del tiempo, pero eso es lo que usaría. –

Respuesta

14

Las llamadas al sistema tardan al menos 1-2 microsegundos en la mayoría de las máquinas modernas solo para la sobrecarga syscall, y mucho más tiempo si están haciendo algo complejo que podría bloquear o dormir. Espere al menos 20 microsegundos y hasta el orden de milisegundos para IO. Compare esto con una pequeña llamada de función o macro que lea un byte de un buffer de espacio de usuario, que probablemente se complete en cuestión de nanosegundos (tal vez 200 ns en un mal día).

+4

+1, gracias por no ser todo místico y nihilista acerca de los problemas de rendimiento como muchos otros. –

+0

Sí, no es la sobrecarga de 'syscall' de la que debe preocuparse: ¡es el trabajo que hace la llamada del sistema lento! – Gabe

+2

@Gabe: No es tan simple, al menos no en todos los casos. Para realizar IO real, el trabajo es moderadamente costoso, pero para multiplexar IO ('select'), timing (' nanosleep'), control de señal ('sigprocmask'), objetos de sincronización (' futex'), y muchos otros casos, el el tiempo total está dominado por la sobrecarga de syscall y no por ningún trabajo realizado. De hecho, para muchos propósitos, el factor constante de la tara de syscall es tan grande que es práctico contar solo syscalls (es decir, considerar todo lo demás 'O (0)') para calcular cómo el tiempo escalan con los datos del tamaño real. –

3

Puede medir esto usted mismo. Simplemente abra /dev/zero y lea y escriba mientras mide el tiempo. También varía la cantidad de bytes que coloca en cada llamada, p. Ej. 1 bytes, 2 bytes, 128 bytes, .. 4096bytes. También tenga cuidado de usar las llamadas de sistema read(2) y write(2) y nada utilizando los almacenamientos intermedios internos.

+0

Si bien esta es una buena idea, '/ dev/zero' no incluye ninguna E/S real, por lo que es posible que no proporcione respuestas precisas. – Gabe

+1

@Gabe: Ese es exactamente el punto. James quería saber la I/O _syscall overhead_, no el tiempo para la transferencia real de datos a los discos. Hacer la E/S en un dispositivo de bloque basado en RAM proporciona una muy buena aproximación de esta sobrecarga. –

+0

Para ilustrar mi punto, si realiza muchas escrituras en un socket de red, puede enviar muchos paquetes pequeños en lugar de muchos más grandes. Esto podría causar congestión en la red y reducir la velocidad. Si ese fuera el caso, nunca lo descubrirías escribiendo a '/ dev/zero'. – Gabe