Weiß jemand Warum die Perf immer zeigen _raw_spin_unlock_irqrestore oder eine andere Spin-Entsperr-Funktion? Die Implementierung von spin_unlock ist normalerweise einfacher als spin_lock. Wenn der Spin_lock stark konkurriert, sollte die Perf das Ergebnis nicht in spin_lock anzeigen?Warum die Perf immer zeigen _raw_spin_unlock_irqrestore oder eine andere Spin entsperren-Funktion
Welche Arbeitslast führen Sie aus? Bist du sicher, dass es Streit gibt?
irq_restore erscheint, weil das erneute Aktivieren von Interrupts teuer ist, aber Sperren, die mit Interrupts spielen, werden nicht oft angezeigt. Sie werden es am ehesten sehen, wenn die Maschine weitgehend untätig ist.
für Kicks, lief ich eine triviale Arbeitsbelastung, die auf einem spinlock behauptet und unsuprisingly war es die Verriegelungsroutine, die wurde, zeigt das:
81.36% [kernel] [k] native_queued_spin_lock_slowpath
4.67% libc-2.17.so [.] __memset_sse2
1.63% [kernel] [k] find_next_zero_bit
0.92% [kernel] [k] _raw_spin_lock
0.81% [kernel] [k] __audit_syscall_exit
0.76% [kernel] [k] __alloc_fd
0.69% [kernel] [k] __slab_free
0.62% [kernel] [k] security_compute_sid.part.13
0.45% [kernel] [k] kmem_cache_free
@employee des Monats Fragment meiner perf Top-Ergebnis
3.32% [kernel] [k] native_queued_spin_lock_slowpath
3.18% [kernel] [k] update_load_avg
3.13% [kernel] [k] __switch_to
3.12% [kernel] [k] native_write_msr
3.02% [kernel] [k] __sched_text_start
2.81% [kernel] [k] _raw_spin_lock
2.20% [kernel] [k] _raw_spin_lock_irqsave
1.97% [kernel] [k] switch_mm_irqs_off
1.70% [kernel] [k] __blkdev_direct_IO_simple
1.69% [kernel] [k] __get_user_pages_fast
Und das ist mein FrameGraph führen enter image description here
flamesgraphen als Bilder sind nicht sehr nützlich. Unter der Annahme, dass Sie die gleiche Workload ausgeführt haben und das Ergebnis wiederholbar ist, können Sie sehen, dass die CPU-Zeit * nicht * in irqrestore verbracht wurde. Ich habe einen Verdacht, was vor sich geht. Der Kernel verfügt über dedizierte Interrupt-Stacks. Wenn die Routine irqrestore ausführt, werden alle Interrupts in der Warteschlange verarbeitet. aber der Berichtsmodus, der Rückverfolgungen erhält, prüft den Unterbrechungsstapel nicht, also erhältst du nur einen Dump mit irqrestore oben. –
hmm, es scheint, dass der framegraph nicht so genau ist. Aus dem Ergebnis von perf top hat _raw_spin_unlock_irqrestore() nicht so viel CPU gekostet. Danke für deinen freundlichen Vorschlag. –
Vielen Dank für Ihre ausführliche Antwort. –
Ich habe gerade einen zufälligen Lese-Test-Fall auf meinem lokalen und verwendet perf, um den konkurrierenden Status des neuesten Block-mq zu überprüfen. Im Ergebnis gibt es außer dem Pfad native_queued_spin_lock_slowpath, der vom io Scheduler aufgerufen werden soll, auch den Pfad _raw_spin_unlock_irqrestore. Vor allem in dem von FrameGraph erzeugten Ergebnis. –