2

アップデート

時間分解能を確認した後、カーネル空間で問題をデバッグしようとしました。

unsigned long long task_sched_runtime(struct task_struct *p)
{
    unsigned long flags;
    struct rq *rq;
    u64 ns = 0;

    rq = task_rq_lock(p, &flags);
    ns = p->se.sum_exec_runtime + do_task_delta_exec(p, rq);
    task_rq_unlock(rq, &flags);

    //printk("task_sched runtime\n");
    return ns; 
}

私たちの新しい実験は、時間p->se.sum_exec_runtimeが即座に更新されないことを示しています。printk()しかし、関数内に追加すると。時刻は即座に更新されます。

年

私たちはAndroidプログラムを開発しています。ただし、関数によって測定された時間は、threadCpuTimenanos()当社のプラットフォームでは常に正しいとは限りません。

clock_gettime実験の結果、から返された時間がすぐに更新されないことがわかりました。while ループを何回か繰り返しても、得られる時間は変わりません。

サンプルコードは次のとおりです。

while(1)
{
    test = 1;
    test = clock_gettime(CLOCK_THREAD_CPUTIME_ID, &now);

    printf(" clock gettime test 1 %lx, %lx , ret = %d\n",now.tv_sec , now.tv_nsec,test );

    pre = now.tv_nsec;
    sleep(1);
}

このコードは x86 PC で問題なく動作します。ただし、カーネル 2.6.35.13 を搭載した組み込みプラットフォーム ARM Cortex-A9 では正しく動作しません。

何か案は？

4

5 に答える 5

2

clock_gettimeをCLOCK_MONOTONIC_RAWを使用するように変更し、スレッドを1つのCPUに割り当てたところ、異なる値が取得されました。デュアルコルテックスA9も使用しています

while(1)
{
    test = 1;
    test = clock_gettime(CLOCK_MONOTONIC_RAW, &now);

    printf(" clock gettime test 1 %lx, %lx , ret = %d\n",now.tv_sec , now.tv_nsec, test );

    pre = now.tv_nsec;
    sleep(1);
}
于 2012-11-20T14:07:59.977 に答える
1

android CTSでも、同じ問題が発生する場合があります。タイマーを2回読み取りますが、同じです

testThreadCpuTimeNanosはandroid.os.cts.DebugTest.testThreadCpuTimeNanosでjunit.framework.AssertionFailedErrorに失敗します

于 2012-07-10T02:41:41.743 に答える
1

$man clock_gettime

...

SMP システムに関する注記

CLOCK_PROCESS_CPUTIME_ID および CLOCK_THREAD_CPUTIME_ID クロックは、CPU (i386 では TSC、Itanium では AR.ITC) からのタイマーを使用して、多くのプラットフォームで実現されます。これらのレジスタは CPU 間で異なる場合があり、その結果、プロセスが別の CPU に移行された場合、これらのクロックは偽の結果を返す可能性があります。

SMP システムの CPU が異なるクロック ソースを持っている場合、各 CPU はわずかに異なる周波数で動作するため、タイマー レジスタ間の相関関係を維持する方法はありません。その場合、clock_getcpuclockid(0) は ENOENT を返し、この状態を示します。2 つのクロックは、プロセスが特定の CPU にとどまることが保証されている場合にのみ役立ちます。

SMP システムのプロセッサは、すべてがまったく同時に開始されるわけではないため、通常、タイマー レジスタはオフセットで実行されます。一部のアーキテクチャには、起動時にこれらのオフセットを制限しようとするコードが含まれています。ただし、コードはオフセットを正確に調整することを保証できません。glibc には、これらのオフセットを処理するための規定が含まれていません (Linux カーネルとは異なります)。通常、これらのオフセットは小さいため、ほとんどの場合、影響は無視できます。

于 2012-08-21T07:36:14.973 に答える
1

の解像度clock_gettimeはプラットフォームに依存します。clock_getres()プラットフォームでの解像度を見つけるために使用します。実験の結果によると、pc-x86 とターゲット プラットフォームのクロック解像度は異なります。

于 2012-06-26T14:58:40.063 に答える
0

CLOCK_THREAD_CPUTIME_IDクロックは、リアルタイムではなく、費やされた CPU 時間を測定します。CPU 時間はほとんどゼロです。また、CLOCK_THREAD_CPUTIME_ID(スレッド固有の CPU 時間) は Linux/glibc では正しく実装されておらず、glibc ではまったく機能しない可能性があります。CLOCK_PROCESS_CPUTIME_IDまたはそれが呼ばれるものは何でもうまくいくはずです。

于 2012-06-26T17:43:06.487 に答える