ア | イ | ウ | エ | オ |
カ | キ | ク | ケ | コ |
サ | シ | ス | セ | ソ |
タ | チ | ツ | テ | ト |
ナ | ニ | ヌ | ネ | ノ |
ハ | ヒ | フ | ヘ | ホ |
マ | ミ | ム | メ | モ |
ヤ | ユ | ヨ | ||
ラ | リ | ル | レ | ロ |
ワ | ヰ | ヴ | ヱ | ヲ |
ン |
A | B | C | D | E |
F | G | H | I | J |
K | L | M | N | O |
P | Q | R | S | T |
U | V | W | X | Y |
Z | 数字 | 記号 |
Linuxカーネルにおいて時刻を記録する、struct timespec型の変数の一つ。
kernel/time/timekeeping.c
struct timekeeper {
struct timespec xtime;
}
実装にもよるが、AndroidのLinuxカーネルでは他に次の変数が構造体中にあり、xtimeを作るために使われている。
u64 xtime_interval;
s64 xtime_remainder;
u32 raw_interval;
u64 xtime_nsec;
CPUが起床している時のタイミングを取るために使うjiffiesと違い、xtimeは、CPUが起床した際にCPUがスリープしていた時間を算出して加算する(らしい)。
このため、CPU以外の外部のクロックソースの情報を参照する。その精度は、環境依存である。
例えば、AndroidのMSM向けLinuxカーネルでは、arch/arm/mach-msm/timer.cに、int64_t msm_timer_get_sclk_time()という関数があり、64ビットのカウンターが得られる。
実装を見ると、マクロの定義の有無でハードウェア構成が選択され、何かしらのクロックソースから直接値を得るか、または共有メモリーSMEM_SMEM_SLOW_CLOCK_VALUEなどからuint32_t型で値を得ていることが分かる。
SMEM_SMEM_SLOW_CLOCK_VALUEがどこで定期的に変更されているのかは定かではない(公開されているソース中から見つからない)が、MSMはマルチプロセッサ構成なので、CPU以外に動作している他のプロセッサーの非公開の処理で常時加算するのだと見込まれる。
得られた値はNSEC_PER_SEC倍された後、グローバル変数sclk_hzで割った商が返却されている。sclk_hzは、32768または32765がセットされるようで、秒間sclk_hz回インクリメントされるものを、ナノ秒単位に変換して提供しているのだということが分かる。ここから、どちらの値にせよ、ナノ秒単位であったとしても分解能は概ね30マイクロ秒程度であることが分かる。
コメントなどを投稿するフォームは、日本語対応時のみ表示されます