Ich arbeite an Leistungsbenchmarking eines SDIO UART Linux / Android-Treibers und verwende current_kernel_time () am Anfang und Ende der zu analysierenden Lese-, Schreibfunktionsimplementierung und drucke dann den Zeitunterschied.
Meistens bekomme ich eine Zeitdifferenz von 0 (null) Nanosekunden (unabhängig von der Größe der zu lesenden / zu schreibenden Daten: 16-2048 Bytes), was ich logisch für falsch halte, nur wenige Male bekomme ich einige Werte Hoffentlich sind diese richtig.
Wie zuverlässig ist die current_kernel_time ()?
Warum bekomme ich die meiste Zeit 0ns?
Ich plane, auf Kernel-Ebene zu profilieren, um mehr Details zu bekommen ... bevor das jemand etwas Licht auf dieses Verhalten werfen kann .. hat irgendjemand irgendetwas ähnliches vorher beobachtet ...
Auch Vorschläge zur Unterstützung / Korrektur meines Benchmarking-Ansatzes sind willkommen!
Danke.
BEARBEITEN:
Dies ist der Lesecode von Linux Kernel Version 2.6.32.9. Ich habe current_kernel_time () wie folgt unter # ifdef-endif:
current_kernel_time ist für die Zeitmessung gedacht, nicht für die Leistungsmessung. Es gibt einen Wert zurück, der nicht auf einem tatsächlichen Timer basiert, sondern auf einem Zeitwert, der durch einen Timer-Interrupt aktualisiert wird. Die Genauigkeit hängt also von der Unterbrechungszeit des Timers ab. und Sie bekommen schlechte Auflösung.
Vielleicht ist getnstimeofday jedoch besser für Ihre Bedürfnisse geeignet, da es auch die tatsächliche Taktquelle zum Anpassen des Zeitwerts liest. Es sollte feinkörniger sein.
Basierend auf der Kernel Quelle ist die beste Funktion vielleicht getrawmonotonic , für den unwahrscheinlichen Fall, dass die Systemzeit während der Messung zurückgestellt wird.
Tags und Links benchmarking linux linux-device-driver linux-kernel