\fBSCHED_FIFO\fP スレッドは I/O 要求によって停止するか、 より高い優先度のスレッドによって置きかえられるか、
\fBsched_yield\fP(2) を呼び出すまで実行を続ける。
-.SS "SCHED_RR: ラウンドロビン (round\-robin)スケジューリング"
+.SS "SCHED_RR: ラウンドロビン (round\-robin) スケジューリング"
.\" On Linux 2.4, the length of the RR interval is influenced
.\" by the process nice value -- MTK
.\"
置きかえられ、その後実行を再開した \fBSCHED_RR\fP スレッドは、そのラウンド
ロビン時間単位を完全に使い切る まで実行される。その時間単位の長さは
\fBsched_rr_get_interval\fP(2) を使って取得できる。
-.SS "SCHED_DEADLINE: Sporadic task model deadline scheduling"
+.SS "SCHED_DEADLINE: 散発タスクモデルのデッドラインスケジューリング"
バージョン 3.14 以降では、 Linux はデッドラインスケジューリングポリシー (\fBSCHED_DEADLINE\fP) が提供される。
現在のところ、 このポリシーは GEDF (Global Earliest Deadline First) を使って CBS (Constant
Bandwidth Server) との組み合わせで実装されている。 このポリシーと関連する属性の設定、取得を行うには、 Linux
固有のシステムコール \fBsched_setattr\fP(2) と \fBsched_getattr\fP(2) を使用する必要がある。
-A sporadic task is one that has a sequence of jobs, where each job is
-activated at most once per period. Each job also has a \fIrelative
-deadline\fP, before which it should finish execution, and a \fIcomputation
-time\fP, which is the CPU time necessary for executing the job. The moment
-when a task wakes up because a new job has to be executed is called the
-\fIarrival time\fP (also referred to as the request time or release time). The
-\fIstart time\fP is the time at which a task starts its execution. The
-\fIabsolute deadline\fP is thus obtained by adding the relative deadline to the
-arrival time.
+散発タスク (sporadic task) はジョブ列を持つタスクで、 各ジョブは期間 (period) あたり多くとも 1 回だけ有効化される。
+各ジョブには \fIrelative deadline\fP (相対デッドライン) と \fIcomputation time\fP (計算時間) がある。
+相対デッドラインは、そのジョブがそのデッドラインより前に実行が終了すべきであることを示す。 計算時間は、このジョブを実行するのに必要な CPU
+時間である。 新しいジョブを実行する必要が出てタスクが起こされる時点は \fIarrival time\fP (到着時刻) と呼ばれる (要求時刻
+(request time) や解放時刻 (release time) と呼ばれることもある)。 \fIstart time\fP
+はタスクが実行を開始する時刻である。 したがって、 \fIabsolute deadline\fP (絶対デッドライン)
+は到着時刻に相対デッドラインを加算することで求められる。
-The following diagram clarifies these terms:
+以下の図はこれらの用語をまとめたものである。
.in +4n
.nf
.fi
.in
-When setting a \fBSCHED_DEADLINE\fP policy for a thread using
-\fBsched_setattr\fP(2), one can specify three parameters: \fIRuntime\fP,
-\fIDeadline\fP, and \fIPeriod\fP. These parameters do not necessarily correspond
-to the aforementioned terms: usual practice is to set Runtime to something
-bigger than the average computation time (or worst\-case execution time for
-hard real\-time tasks), Deadline to the relative deadline, and Period to the
-period of the task. Thus, for \fBSCHED_DEADLINE\fP scheduling, we have:
+\fBsched_setattr\fP(2) を使ってスレッドに \fBSCHED_DEADLINE\fP ポリシーを設定する際、 \fIRuntime\fP,
+\fIDeadline\fP, \fIPeriod\fP の 3 つのパラメーターを指定することができる。
+これらのパラメーターは必ずしも上で述べた用語に対応しているわけではない。 よくある方法としては、 Runtime に平均計算時間
+(もしくはハードリアルタイムタスクの場合は最悪ケースの実行時間) よりも大きな値を、 Deadline に相対デッドラインを、 Period
+にタスクの期間 (period) を設定する。 したがって、 \fBSCHED_DEADLINE\fP スケジューリングでは、 以下のようになる。
.in +4n
.nf
.\" FIXME It looks as though specifying sched_period as 0 means
.\" "make sched_period the same as sched_deadline".
.\" This needs to be documented.
-3 角デッドラインスケジューリングパラメーターは \fIsched_attr\fP 構造体の \fIsched_runtime\fP,
+3 つのデッドラインスケジューリングパラメーターは \fIsched_attr\fP 構造体の \fIsched_runtime\fP,
\fIsched_deadline\fP, \fIsched_period\fP フィールドに対応する。 これらのフィールドはナノ秒単位の値である。
\fIsched_period\fP に 0 が指定された場合 \fIsched_deadline\fP と同じ値になる。
sched_runtime <= sched_deadline <= sched_period
.\" See __checkparam_dl in kernel/sched/core.c
-In addition, under the current implementation, all of the parameter values
-must be at least 1024 (i.e., just over one microsecond, which is the
-resolution of the implementation), and less than 2^63. If any of these
-checks fails, \fBsched_setattr\fP(2) fails with the error \fBEINVAL\fP.
-
-The CBS guarantees non\-interference between tasks, by throttling threads
-that attempt to over\-run their specified Runtime.
-
-To ensure deadline scheduling guarantees, the kernel must prevent situations
-where the set of \fBSCHED_DEADLINE\fP threads is not feasible (schedulable)
-within the given constraints. The kernel thus performs an admittance test
-when setting or changing \fBSCHED_DEADLINE\fP policy and attributes. This
-admission test calculates whether the change is feasible; if it is not
-\fBsched_setattr\fP(2) fails with the error \fBEBUSY\fP.
-
-For example, it is required (but not necessarily sufficient) for the total
-utilization to be less than or equal to the total number of CPUs available,
-where, since each thread can maximally run for Runtime per Period, that
-thread's utilization is its Runtime divided by its Period.
-
-In order to fulfil the guarantees that are made when a thread is admitted to
-the \fBSCHED_DEADLINE\fP policy, \fBSCHED_DEADLINE\fP threads are the highest
-priority (user controllable) threads in the system; if any \fBSCHED_DEADLINE\fP
-thread is runnable, it will preempt any thread scheduled under one of the
-other policies.
-
-A call to \fBfork\fP(2) by a thread scheduled under the \fBSCHED_DEADLINE\fP
-policy will fail with the error \fBEAGAIN\fP, unless the thread has its
-reset\-on\-fork flag set (see below).
+これに加えて、 現在の実装では、 すべてのパラメーター値は少なくとも 1024 (実装の粒度である 1 マイクロ秒よりも少しだけ大きな値) で 2^63
+よりも小さくなければならない。 これらのチェックのいずれかが失敗すると、 \fBsched_setattr\fP(2) はエラー \fBEINVAL\fP
+で失敗する。
+
+CBS によりタスク間の干渉がないことが保証される。 指定された Runtime を超えて実行しようとしたスレッドは絞り込まれることになる。
+
+デッドラインスケジューリングの保証がきちんと機能するためには、 カーネルは \fBSCHEDULING\fP スレッドの集合が指定された制約条件におさまらない
+(スケジューリングできない) 状況を防止しなければならない。 そのため、カーネルは \fBSCHED_DEADLINE\fP
+ポリシーと属性を設定、変更する際に、受け入れチェック (admittance test) を実行する。
+この受け入れチェックは、変更が実行可能かを計算し、もし実行できないようであれば \fBsched_setattr\fP(2) はエラー \fBEBUSY\fP
+で失敗する。
+
+例えば、 使用率の合計が利用可能な合計 CPU 数以下である必要がある (ただし、必ずしも十分というわけではない)。 なお、 各スレッドは最大で
+Period あたり Runtime だけ実行されることがあるので、 そのスレッドの使用率は Runtime を Period で割ったものとなる。
+
+スレッドが \fBSCHED_DEADLINE\fP ポリシーに受け入れられた場合に保証を実現するため、 \fBSCHED_DEADLINE\fP
+スレッドはシステムで (ユーザーが制御可能な) 最高優先度のスレッドとなる。 いずれかの \fBSCHED_DEADLINE\fP
+スレッドが実行可能であれば、 他のポリシーでスケジューリングされているスレッドはすべて横取りされる。
+
+\fBSCHED_DEADLINE\fP ポリシーでスケジューリングされているスレッドが \fBfork\fP(2) を呼び出すと、 そのスレッドで
+reset\-on\-fork フラグがセットされている場合 (下記参照) を除き、 エラー \fBEAGAIN\fP で失敗する。
.\"
.\" FIXME Calling sched_getparam() on a SCHED_DEADLINE thread
.\" fails with EINVAL, but sched_getscheduler() succeeds.
.\" Is that intended? (Why?)
.\"
-A \fBSCHED_DEADLINE\fP thread that calls \fBsched_yield\fP(2) will yield the
-current job and wait for a new period to begin.
+\fBSCHED_DEADLINE\fP スレッドが \fBsched_yield\fP(2) を呼び出すと、 現在のジョブが CPU
+を明け渡し、新しい期間が開始するのを待つ。
.SS "SCHED_OTHER: Linux のデフォルトの時分割スケジューリング"
.\"
\fBSCHED_OTHER\fP は静的優先度 0 でのみ使用できる。 \fBSCHED_OTHER\fP は Linux 標準の時分割スケジューラで、
msgstr ""
"Project-Id-Version: PACKAGE VERSION\n"
"POT-Creation-Date: 2015-01-07 18:28+0900\n"
-"PO-Revision-Date: 2015-01-09 04:00+0900\n"
+"PO-Revision-Date: 2015-01-09 08:28+0900\n"
"Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
"Language-Team: LANGUAGE <LL@li.org>\n"
"Language: \n"
#: build/C/man7/sched.7:177
#, no-wrap
msgid "SCHED_RR: Round-robin scheduling"
-msgstr "SCHED_RR: ラウンドロビン (round-robin)スケジューリング"
+msgstr "SCHED_RR: ラウンドロビン (round-robin) スケジューリング"
#. On Linux 2.4, the length of the RR interval is influenced
#. by the process nice value -- MTK
#: build/C/man7/sched.7:196
#, no-wrap
msgid "SCHED_DEADLINE: Sporadic task model deadline scheduling"
-msgstr ""
+msgstr "SCHED_DEADLINE: 散発タスクモデルのデッドラインスケジューリング"
#. type: Plain text
#: build/C/man7/sched.7:208
"I<start time> is the time at which a task starts its execution. The "
"I<absolute deadline> is thus obtained by adding the relative deadline to the "
"arrival time."
-msgstr ""
+msgstr "散発タスク (sporadic task) はジョブ列を持つタスクで、 各ジョブは期間 (period) あたり多くとも 1 回だけ有効化される。 各ジョブには I<relative deadline> (相対デッドライン) と I<computation time> (計算時間) がある。 相対デッドラインは、そのジョブがそのデッドラインより前に実行が終了すべきであることを示す。 計算時間は、このジョブを実行するのに必要な CPU 時間である。 新しいジョブを実行する必要が出てタスクが起こされる時点は I<arrival time> (到着時刻) と呼ばれる (要求時刻 (request time) や解放時刻 (release time) と呼ばれることもある)。 I<start time> はタスクが実行を開始する時刻である。 したがって、 I<absolute deadline> (絶対デッドライン) は到着時刻に相対デッドラインを加算することで求められる。\n"
#. type: Plain text
#: build/C/man7/sched.7:228
msgid "The following diagram clarifies these terms:"
-msgstr ""
+msgstr "以下の図はこれらの用語をまとめたものである。"
#. type: Plain text
#: build/C/man7/sched.7:239
"bigger than the average computation time (or worst-case execution time for "
"hard real-time tasks), Deadline to the relative deadline, and Period to the "
"period of the task. Thus, for B<SCHED_DEADLINE> scheduling, we have:"
-msgstr ""
+msgstr "B<sched_setattr>(2) を使ってスレッドに B<SCHED_DEADLINE> ポリシーを設定する際、 I<Runtime>, I<Deadline>, I<Period> の 3 つのパラメーターを指定することができる。 これらのパラメーターは必ずしも上で述べた用語に対応しているわけではない。 よくある方法としては、 Runtime に平均計算時間 (もしくはハードリアルタイムタスクの場合は最悪ケースの実行時間) よりも大きな値を、 Deadline に相対デッドラインを、 Period にタスクの期間 (period) を設定する。 したがって、 B<SCHED_DEADLINE> スケジューリングでは、 以下のようになる。"
#. type: Plain text
#: build/C/man7/sched.7:269
"structure; see B<sched_setattr>(2). These fields express value in "
"nanoseconds. If I<sched_period> is specified as 0, then it is made the same "
"as I<sched_deadline>."
-msgstr "3 角デッドラインスケジューリングパラメーターは I<sched_attr> 構造体の I<sched_runtime>, I<sched_deadline>, I<sched_period> フィールドに対応する。 これらのフィールドはナノ秒単位の値である。 I<sched_period> に 0 が指定された場合 I<sched_deadline> と同じ値になる。"
+msgstr "3 つのデッドラインスケジューリングパラメーターは I<sched_attr> 構造体の I<sched_runtime>, I<sched_deadline>, I<sched_period> フィールドに対応する。 これらのフィールドはナノ秒単位の値である。 I<sched_period> に 0 が指定された場合 I<sched_deadline> と同じ値になる。"
#. type: Plain text
#: build/C/man7/sched.7:291
"must be at least 1024 (i.e., just over one microsecond, which is the "
"resolution of the implementation), and less than 2^63. If any of these "
"checks fails, B<sched_setattr>(2) fails with the error B<EINVAL>."
-msgstr ""
+msgstr "これに加えて、 現在の実装では、 すべてのパラメーター値は少なくとも 1024 (実装の粒度である 1 マイクロ秒よりも少しだけ大きな値) で 2^63 よりも小さくなければならない。 これらのチェックのいずれかが失敗すると、 B<sched_setattr>(2) はエラー B<EINVAL> で失敗する。"
#. type: Plain text
#: build/C/man7/sched.7:306
msgid ""
"The CBS guarantees non-interference between tasks, by throttling threads "
"that attempt to over-run their specified Runtime."
-msgstr ""
+msgstr "CBS によりタスク間の干渉がないことが保証される。 指定された Runtime を超えて実行しようとしたスレッドは絞り込まれることになる。"
#. type: Plain text
#: build/C/man7/sched.7:319
"when setting or changing B<SCHED_DEADLINE> policy and attributes. This "
"admission test calculates whether the change is feasible; if it is not "
"B<sched_setattr>(2) fails with the error B<EBUSY>."
-msgstr ""
+msgstr "デッドラインスケジューリングの保証がきちんと機能するためには、 カーネルは B<SCHEDULING> スレッドの集合が指定された制約条件におさまらない (スケジューリングできない) 状況を防止しなければならない。 そのため、カーネルは B<SCHED_DEADLINE> ポリシーと属性を設定、変更する際に、受け入れチェック (admittance test) を実行する。 この受け入れチェックは、変更が実行可能かを計算し、もし実行できないようであれば B<sched_setattr>(2) はエラー B<EBUSY> で失敗する。"
#. type: Plain text
#: build/C/man7/sched.7:325
"utilization to be less than or equal to the total number of CPUs available, "
"where, since each thread can maximally run for Runtime per Period, that "
"thread's utilization is its Runtime divided by its Period."
-msgstr ""
+msgstr "例えば、 使用率の合計が利用可能な合計 CPU 数以下である必要がある (ただし、必ずしも十分というわけではない)。 なお、 各スレッドは最大で Period あたり Runtime だけ実行されることがあるので、 そのスレッドの使用率は Runtime を Period で割ったものとなる。"
#. type: Plain text
#: build/C/man7/sched.7:336
"priority (user controllable) threads in the system; if any B<SCHED_DEADLINE> "
"thread is runnable, it will preempt any thread scheduled under one of the "
"other policies."
-msgstr ""
+msgstr "スレッドが B<SCHED_DEADLINE> ポリシーに受け入れられた場合に保証を実現するため、 B<SCHED_DEADLINE> スレッドはシステムで (ユーザーが制御可能な) 最高優先度のスレッドとなる。 いずれかの B<SCHED_DEADLINE> スレッドが実行可能であれば、 他のポリシーでスケジューリングされているスレッドはすべて横取りされる。"
#. type: Plain text
#: build/C/man7/sched.7:344
"A call to B<fork>(2) by a thread scheduled under the B<SCHED_DEADLINE> "
"policy will fail with the error B<EAGAIN>, unless the thread has its reset-"
"on-fork flag set (see below)."
-msgstr ""
+msgstr "B<SCHED_DEADLINE> ポリシーでスケジューリングされているスレッドが B<fork>(2) を呼び出すと、 そのスレッドで reset-on-fork フラグがセットされている場合 (下記参照) を除き、 エラー B<EAGAIN> で失敗する。"
#
#. FIXME Calling sched_getparam() on a SCHED_DEADLINE thread
msgid ""
"A B<SCHED_DEADLINE> thread that calls B<sched_yield>(2) will yield the "
"current job and wait for a new period to begin."
-msgstr ""
+msgstr "B<SCHED_DEADLINE> スレッドが B<sched_yield>(2) を呼び出すと、 現在のジョブが CPU を明け渡し、新しい期間が開始するのを待つ。"
#. type: SS
#: build/C/man7/sched.7:355
OSDN Git Service
