私はこれを知っておりsched_rt_period_us、sched_rt_runtime_usRTタスクが手につかない場合にシステムが停止するのを防ぐためです。ただし、sched_rt_period_usジョブを円滑に実行するには、より小さい値を使用できるかどうか疑問に思います。
呼び出しごとのCPU時間が1ミリ秒ほどかかる簡単な作業があります。たとえば、GPIOピンを介してステッピングモータを駆動します。しかし、私は毎秒100サイクル以上を継続的に達成したいと思います。これは、プリエンプションおよびスケジューラのオーバーヘッドを除くCPU時間の10％を超えません。
「sched_rt_period_usの値が小さすぎると、システムが不安定になる可能性がある」という記事を読みました。1ただし、「非常に小さい値」を構成するサイズの順序については説明しない。sched_rt_period_us10000に設定し、sched_yield()時々制御（）を返すと、プログラム呼び出し間の遅延が0.01秒を超えないと思いますか？
デフォルトのCPUはおそらく850MHz ARMであり、上記のコントロールに加えて他の多くの作業がありますが、それらのどれもリアルタイムではなく、「応答性」を感じる必要もなく、まだデフォルトと同じではなくsched_rt_period_us（sched_rt_runtime_us1の95％）2番目）一度に0.05秒間スリープモードに切り替えることはできません。
ベストアンサー1
これは古い質問です。試してみます。私が理解したところによると、あなたはデッドロック機構（これ）RTプロセスによる正常なプロセス飢餓を防止します。
あなたはそう言った
呼び出しごとのCPU時間が1ミリ秒ほどかかる簡単な作業があります。
一つですか？短いサイクル操作それとも外部入力によって開始された短いタスクですか？
最初のケース（短期作業）：Linuxで知っておくべきことカーネル 3.14利用可能SCHED_DEADLINEクラス。これにより、定期的に少なくともこの程度のCPU時間を持つようにプロセスのスケジューリングポリシーを設定できます。それを見て文書SCHED_DEADLINE、セクションでわかりやすい図を見つけることもできます。男7配置。トリガーが外部（ランダム、非周期的）の場合、解決策ではない可能性があります。
2番目のケース（短い散発的な仕事）：プログラムが必要なときはいつでもタスクの小さな部分だけを実行すると主張できる場合は、優先順位の使用を中止して呼び出しを実行できます。sched_yield作業が完了したら。プーリングで忙しい場合、これはbaアプローチです。本当に優先順位が必要な場合は補足することもできます。眠る、RTプロセスがスリープモードの間、非RTプロセスが実行されます。割り込みによってトリガされる場合は、次を使用する必要があることもわかります。下、より難しい方法です。
それに加えて、より多くのものがあります。実際のプロセスよりも多くのライブプロセスがある可能性があることを覚えておく必要があります。例えば、カーネルスレッド。