15

私が理解しているように、USER_HZ定数は Linux 2.6 で追加され、ユーザー空間の値の期待から生じる問題を解決しました。Linux のHZ以前のバージョンでは、値を変更するHZと、ユーザー空間アプリケーションの値が意図せずにスケーリングされる可能性があります。

USER_HZ定数がこのスケーリングの問題をどのように解決するかについて混乱しています。たとえば、ユーザー空間アプリケーションが jiffies を秒に変換するとします。

long MY_HZ = sysconf(_SC_CLK_TCK);

/* num_jiffies acquired from /proc but
 * simplified to 1000 here for clarity */
long num_jiffies = 1000;

long num_seconds = num_jiffies / MY_HZ;

ユーザー空間アプリケーションは呼び出しHZを介して値を決定してsysconfいるため、スケーリングの問題を防ぐことはできませんか?

一方、ユーザー空間アプリケーションのソースにハードコードされた値があった場合、HZ定数はスケーリングの問題をどのように防止しますか? ユーザー空間アプリケーションは、システムの.ハードコードされた定数が一致する保証はありませんか？USER_HZUSER_HZUSER_HZ

さらに、ユーザー空間で利用可能なすべてのクロックティック値 (例: /proc) はすでに にスケーリングされていUSER_HZますか? ユーザー空間プログラムは、 jiffiesの値が にスケーリングされているか にスケーリングされているかをどのように認識しますHZかUSER_HZ?

4

2 に答える 2

7

Linux Kernel Development (または第 2 版のオンライン バージョン)から

2.6 より前のカーネルでは、 の値を変更するHZと、ユーザー空間の異常が発生しました。これは、値がティック/秒単位でユーザー空間にエクスポートされたために発生しました。これらのインターフェイスが恒久的になるにつれて、アプリケーションは の特定の値に依存するようになりましたHZ。その結果、変更HZすると、エクスポートされたさまざまな値が何らかの定数でスケーリングされますが、ユーザー空間は認識しません。稼働時間は、実際には 2 時間だったのに 20 時間と表示されます。

このような問題を防ぐために、カーネルはエクスポートされたすべての jiffies 値をスケーリングする必要があります。これは 、ユーザー空間が期待する値でUSER_HZある を定義することによって行われます。HZx86 では、HZ歴史的に 100 だったので、USER_HZ100 です。

USER_HZユーザー空間にエクスポートされると、常に 1 秒あたりのティック数がスケーリングされます。

于 2013-07-01T20:42:01.257 に答える