誰かが知っていますか？perfが常に_raw_spin_unlock_irqrestoreまたはその他のスピンロック解除機能を表示するのはなぜですか？ spin_unlockの実装は、通常、spin_lockと比較して簡単です。 spin_lockに大きな競合がある場合、perfはspin_lockに結果を表示しませんか？perfが常に_raw_spin_unlock_irqrestoreまたはその他のスピンロック解除機能を表示する理由
あなたはどのワークロードを実行していますか？最初に競合があると確信していますか？
割り込みを再度有効にするにはコストがかかりますが、割り込みで再生されるロックは非常に頻繁に表示されないため、irq_restoreが表示されます。マシンが大部分アイドル状態になっているときに、そのマシンを表示する可能性が最も高くなります。キックのため
、私はスピンロックに主張些細なワークロードを実行し、unsuprisinglyそれが最もまで見せていたロックルーチンだった：私のPERFトップ結果の月 断片の
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を
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
そして、これはあなたの詳細な応答のための enter image description here
写真としての写真は非常に有用ではありません。あなたが同じワークロードを実行していて、結果が反復可能であると仮定すると、cpu時間はirqrestoreで費やされていないことがわかります。私は何が起こっているのか疑いがあります。カーネルは専用の割り込みスタックを持っています。ルーチンがirqrestoreを実行すると、すべてのキューに入れられた割り込みが現在処理されています。バックトレースを取得しているレポーティングモードでは割り込みスタックは検査されないので、先頭にirqrestoreを持つダンプだけが得られます。 –
ええと、フレームグラフはそれほど正確ではないようです。 perf topの結果から、_raw_spin_unlock_irqrestore（）はCPUのコストがあまり高くありませんでした。あなたの親切な提案に感謝します。 –
おかげで私のFrameGraph結果です。 –
私は最新のブロック-mqの競合状態をチェックするために、ローカルと使用されたperfでランダムな読み込みテストケースを実行しました。その結果、ioスケジューラによって呼び出されるnative_queued_spin_lock_slowpathパスを除き、_raw_spin_unlock_irqrestoreパスもあります。特に、FrameGraphによって生成された結果。 –