2

ARM Cortex-A8を使用しており、アセンブリコードを介してCCNTタイムカウンターから値を読み取ろうとしています。私はこの投稿をフォローしていますARMCortex-A8プロセッサでプログラムの実行時間を測定する方法は？ 。それに応じて、タイマーから値を読み取る前に、カウンターを有効にし、64ビット分周器を有効にしてオーバーフローをクリアする必要があります。これらの操作は、適切なレジスタ（たとえば、PMCR（パフォーマンスモニトロ制御レジスタ））内に書き込むことによって実行されます。したがって、オーバーフローがどのように発生するかを追跡するために、ループ内にカウンター値が出力され、次の動作が発生します。

1           (starts to incrementing after it was reset to zero)
4650
4858
4943
5023
...
...        (incrementing...)
...
4293939054
4293939128       (overflow happens)
1602570          
1602703
1602788
...
...
4293522911
4293522987
4293523062
4293523137
1186243
1186367
1186453
1186536
1186612
1186686
...
4293536300
4293536377
4293536456
4293536533
4293536612
1199090
1199209
1199295
1199373
1199453
1199530
….
and so forth.

したがって、私は一連の質問があります：

a）Linuxカーネルで使用されているレジスタはどれですか？（今後のカーネルバージョンの情報はどれほど信頼できるか）。それらの値の変更はどれほど安全でしょうか？

b）CCNT周波数の正確な値とその取得方法は何ですか？残念ながら、プロセッサの仕様に値が見つかりません。しかし、dmesgはそれを言います

[ 0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz
[ 0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 178956ms
[ 0.132855] Switching to clocksource gp timer

しかし、clock_gettimeに対して手動で識別すると、7MHzになります。では、なぜそれが期待どおりに24MHzではないのでしょうか。

c）私の最初の出力によると、オーバーフロー後、ゼロではなく約1ミルから始まるのはなぜですか？

d）64分周器がないと、間違った結果が得られるのはなぜですか？値は次のようにジャンプし始めます。

...
134110099
134114934
134119656
302352300
302361825
302367135
…
2885588930
2885593776
2885598630
3053958670
3053966752
3053972232
…
261130096
261134909
429343853
429351487
429356735

助けていただければ幸いです。ありがとう

4

1 に答える 1

4

a）PMU regは、Linuxカーネルのperfサブシステムによって使用される場合があります（perfユーザースペースツールを介してアクセスされます）。

b）CCNT周波数は、Cortex-A9 CPUサイクルカウンター、または分周器を有効にした場合はサイクル/64です。したがって、分周器を備えた7MHzは、約450MHzの平均CPUクロックになります。これは、24MHzのシステムクロックとは別のものです。

c）プロセスがスケジュールされた可能性があります。これは、プロセスだけでなく、CPU全体の低レベルのサイクルカウンターです。カーネルまたは別のプロセスで実行を継続します。一方、プロセスが別のCPUに移行する場合は、そのCPUのサイクルカウンターにアクセスします（同じ仕切り設定がない場合もあります）。一貫したカウントが必要な場合は、プロセスを1つのCPUに固定する必要があります。

d）（c）と同様の回答で、プロセスのスケジューリングと移行の効果が見られる場合があります。

于 2013-01-04T15:46:14.873 に答える