私はLinux カーネルの try_to_wake_up() 関数をもう少しよく理解しようとしてきました。概念的には、プロセスをウェイクアップするには、プロセスを CPU ランキューに追加する必要があると (考えています)、これがどこで発生しているのかを理解するのに苦労しています。
//try_to_wake_up()
if (p == current) {
/* I omitted some comments here*/
success = 1;
cpu = task_cpu(p); //task_cpu(p) returns READ_ONCE(p->cpu);
trace_sched_waking(p); //This is just a logging call
p->state = TASK_RUNNING;
trace_sched_wakeup(p); //Another logging call
goto out;
}
したがって、task_cpu()は CPU ランキューをまったく変更していないように見えるので、ttwu_stat() を呼び出しているラベルを調べることにしました。
/*I omitted some intermediate code here*/
out:
if (success)
ttwu_stat(p, cpu, wake_flags);
preempt_enable();
return success;
しかし、次にttwu_stat() を見てみると、入力引数をインクリメントするだけのこの__schedstat_incマクロへの呼び出しの束のように見えます。
それでは...実際に task_struct* p を CPU 実行キューに追加する場所はどこですか?
どんな考えでも感謝します。
ありがとう。
あなたが引用したコード ブロックは、省略されたコメントで説明されているように、特殊なケースです。
* We're waking current, this means 'p->on_rq' and 'task_cpu(p)
* == smp_processor_id()'. Together this means we can special
* case the whole 'p->on_rq && ttwu_remote()' case below
* without taking any locks.
ウェイクアップするタスクは現在のタスクであるため、すでに実行キュー ( p->on_rq) にあるため、追加する必要はありません。
cpu = select_task_rq(p, p->wake_cpu, SD_BALANCE_WAKE, wake_flags);
これにより、タスクが実行キューに追加され、スケジュールされている CPU が返されるため、必要に応じて移行を処理できます。
#ifdef CONFIG_SMP条件のメリットは、いくつかの説明は：SMPがサポートされていない場合は、複数のタスクをすることはできません同時に実行し、我々は現在のタスクを目覚めていない知っているので、対処する唯一のシナリオは、I / O待ちです。
この記事はインターネットから収集されたものであり、転載の際にはソースを示してください。
侵害の場合は、連絡してください[email protected]
コメントを追加