00000009.htm

水木社区 embeded 版精华区 下载

to&nbsp;avoid&nbsp;being&nbsp;swapped&nbsp;out.&nbsp;This&nbsp;guarantees&nbsp;that&nbsp;the&nbsp;real-time&nbsp;<br />
application&nbsp;can&nbsp;react&nbsp;as&nbsp;soon&nbsp;as&nbsp;possible&nbsp;on&nbsp;any&nbsp;interrupts&nbsp;and&nbsp;that&nbsp;<br />
the&nbsp;response&nbsp;time&nbsp;will&nbsp;not&nbsp;be&nbsp;influenced&nbsp;by&nbsp;the&nbsp;complicated&nbsp;normal&nbsp;<br />
Linux&nbsp;time-sharing&nbsp;priority&nbsp;mechanisms&nbsp;or&nbsp;by&nbsp;paging.&nbsp;However,&nbsp;please&nbsp;<br />
read&nbsp;also&nbsp;the&nbsp;chapter&nbsp;on&nbsp;interrupt&nbsp;dispatch&nbsp;latency&nbsp;below!&nbsp;<br />
The&nbsp;new&nbsp;functions&nbsp;are&nbsp;here:&nbsp;<br />
sched_setparam(),&nbsp;sched_getparam(),&nbsp;sched_setscheduler(),&nbsp;<br />
sched_getscheduler(),&nbsp;sched_yield(),&nbsp;sched_get_priority_max(),&nbsp;<br />
sched_get_priority_min(),&nbsp;sched_rr_get_interval().&nbsp;<br />
Implementation&nbsp;status:&nbsp;The&nbsp;sched_*()&nbsp;system&nbsp;calls&nbsp;are&nbsp;now&nbsp;available&nbsp;<br />
since&nbsp;Linux&nbsp;1.3.55&nbsp;(Markus&nbsp;Kuhn&nbsp;&lt;<a href="mailto:[e-mail]>).">[e-mail]>).</a>&nbsp;<br />
Although&nbsp;much&nbsp;testing,&nbsp;performance&nbsp;evaluation,&nbsp;and&nbsp;optimization&nbsp;with&nbsp;<br />
the&nbsp;real-time&nbsp;scheduler&nbsp;is&nbsp;necessary&nbsp;(especially&nbsp;with&nbsp;regard&nbsp;to&nbsp;&quot;fast&nbsp;<br />
interrupt&nbsp;handling,&nbsp;see&nbsp;below),&nbsp;you&nbsp;can&nbsp;already&nbsp;use&nbsp;the&nbsp;sched_*()&nbsp;<br />
calls&nbsp;in&nbsp;order&nbsp;to&nbsp;get&nbsp;the&nbsp;processor&nbsp;exclusively.&nbsp;There&nbsp;are&nbsp;also&nbsp;libc&nbsp;<br />
and&nbsp;manual&nbsp;pages&nbsp;available.&nbsp;Some&nbsp;earlier&nbsp;work&nbsp;on&nbsp;this&nbsp;was&nbsp;done&nbsp;by&nbsp;<br />
David&nbsp;F.&nbsp;Carlson&nbsp;&lt;<a href="mailto:[e-mail]>">[e-mail]></a>&nbsp;in&nbsp;his&nbsp;POSIX.4_scheduler&nbsp;patch&nbsp;<br />
against&nbsp;Linux&nbsp;1.2&nbsp;(still&nbsp;available&nbsp;on&nbsp;sunsite).&nbsp;<br />
Asynchronous&nbsp;I/O&nbsp;(aio)&nbsp;<br />
----------------------&nbsp;<br />
POSIX.1b&nbsp;defines&nbsp;a&nbsp;number&nbsp;of&nbsp;functions&nbsp;which&nbsp;allow&nbsp;to&nbsp;send&nbsp;a&nbsp;long&nbsp;list&nbsp;<br />
of&nbsp;read/write&nbsp;requests&nbsp;at&nbsp;various&nbsp;seek&nbsp;positions&nbsp;in&nbsp;various&nbsp;files&nbsp;to&nbsp;<br />
the&nbsp;kernel&nbsp;with&nbsp;one&nbsp;single&nbsp;lio_listio()&nbsp;system&nbsp;call.&nbsp;While&nbsp;the&nbsp;process&nbsp;<br />
continues&nbsp;to&nbsp;execute&nbsp;the&nbsp;next&nbsp;instructions,&nbsp;the&nbsp;kernel&nbsp;will&nbsp;<br />
asynchronously&nbsp;read&nbsp;or&nbsp;write&nbsp;the&nbsp;requested&nbsp;pages&nbsp;and&nbsp;will&nbsp;send&nbsp;signals&nbsp;<br />
when&nbsp;the&nbsp;task&nbsp;has&nbsp;been&nbsp;completed&nbsp;(if&nbsp;this&nbsp;is&nbsp;desired).&nbsp;<br />
This&nbsp;is&nbsp;very&nbsp;nice&nbsp;for&nbsp;a&nbsp;database&nbsp;which&nbsp;knows&nbsp;that&nbsp;it&nbsp;will&nbsp;require&nbsp;a&nbsp;<br />
lot&nbsp;of&nbsp;different&nbsp;blocks&nbsp;scattered&nbsp;on&nbsp;a&nbsp;file.&nbsp;It&nbsp;will&nbsp;simply&nbsp;pass&nbsp;a&nbsp;<br />
list&nbsp;of&nbsp;the&nbsp;blocks&nbsp;to&nbsp;the&nbsp;kernel,&nbsp;and&nbsp;the&nbsp;kernel&nbsp;can&nbsp;optimize&nbsp;the&nbsp;disk&nbsp;<br />
head&nbsp;movement&nbsp;before&nbsp;sending&nbsp;the&nbsp;requests&nbsp;to&nbsp;the&nbsp;device.&nbsp;In&nbsp;addition&nbsp;<br />
this&nbsp;minimizes&nbsp;the&nbsp;number&nbsp;of&nbsp;system&nbsp;calls&nbsp;and&nbsp;allows&nbsp;the&nbsp;database&nbsp;to&nbsp;<br />
do&nbsp;something&nbsp;else&nbsp;in&nbsp;the&nbsp;meantime&nbsp;(e.g.&nbsp;waiting&nbsp;for&nbsp;the&nbsp;client&nbsp;process&nbsp;<br />
sending&nbsp;an&nbsp;abort&nbsp;instruction&nbsp;in&nbsp;which&nbsp;case&nbsp;the&nbsp;database&nbsp;server&nbsp;can&nbsp;<br />
cancel&nbsp;the&nbsp;async&nbsp;i/o&nbsp;requests&nbsp;with&nbsp;aio_cancel()).&nbsp;<br />
Another&nbsp;important&nbsp;application&nbsp;of&nbsp;aio&nbsp;are&nbsp;multimedia&nbsp;systems&nbsp;like&nbsp;MPEG&nbsp;<br />
or&nbsp;sound&nbsp;file&nbsp;players&nbsp;and&nbsp;recorders.&nbsp;These&nbsp;programs&nbsp;want&nbsp;to&nbsp;preload&nbsp;<br />
the&nbsp;next&nbsp;few&nbsp;seconds&nbsp;of&nbsp;the&nbsp;data&nbsp;stream&nbsp;from&nbsp;harddisk&nbsp;into&nbsp;locked&nbsp;<br />
memory,&nbsp;but&nbsp;also&nbsp;want&nbsp;to&nbsp;continue&nbsp;showing&nbsp;the&nbsp;video&nbsp;on&nbsp;the&nbsp;screen&nbsp;at&nbsp;<br />
the&nbsp;same&nbsp;time&nbsp;without&nbsp;any&nbsp;interruptions&nbsp;caused&nbsp;by&nbsp;synchronous&nbsp;I/O.&nbsp;The&nbsp;<br />
POSIX.1b&nbsp;async&nbsp;I/O&nbsp;calls&nbsp;provide&nbsp;a&nbsp;nice&nbsp;way&nbsp;for&nbsp;such&nbsp;anticipatory&nbsp;<br />
loading.&nbsp;<br />
POSIX.1b&nbsp;also&nbsp;defines&nbsp;priorities&nbsp;for&nbsp;asynchronous&nbsp;I/O,&nbsp;i.e.&nbsp;there&nbsp;is&nbsp;a&nbsp;<br />
way&nbsp;to&nbsp;tell&nbsp;the&nbsp;kernel&nbsp;that&nbsp;the&nbsp;read&nbsp;request&nbsp;for&nbsp;the&nbsp;MPEG&nbsp;player&nbsp;is&nbsp;<br />
more&nbsp;important&nbsp;than&nbsp;the&nbsp;read&nbsp;request&nbsp;of&nbsp;gcc.&nbsp;On&nbsp;a&nbsp;future&nbsp;real-time&nbsp;<br />
Linux,&nbsp;you&nbsp;don't&nbsp;want&nbsp;to&nbsp;see&nbsp;any&nbsp;image&nbsp;distortions&nbsp;while&nbsp;watching&nbsp;MPEG&nbsp;<br />
video&nbsp;and&nbsp;compiling&nbsp;a&nbsp;kernel&nbsp;at&nbsp;the&nbsp;same&nbsp;time&nbsp;if&nbsp;you&nbsp;gave&nbsp;the&nbsp;MPEG&nbsp;<br />
player&nbsp;a&nbsp;higher&nbsp;static&nbsp;priority.&nbsp;<br />
New&nbsp;functions&nbsp;in&nbsp;this&nbsp;area&nbsp;are:&nbsp;<br />
aio_read(),&nbsp;aio_write(),&nbsp;lio_listio(),&nbsp;aio_suspend(),&nbsp;aio_cancel(),&nbsp;<br />
aio_error(),&nbsp;aio_return(),&nbsp;aio_fsync().&nbsp;<br />
Implementation&nbsp;status:&nbsp;Not&nbsp;yet&nbsp;implemented.&nbsp;The&nbsp;aio&nbsp;functions&nbsp;are&nbsp;<br />
probably&nbsp;best&nbsp;implemented&nbsp;in&nbsp;libc&nbsp;using&nbsp;kernel&nbsp;threads&nbsp;and&nbsp;the&nbsp;normal&nbsp;<br />
synchronous&nbsp;I/O&nbsp;system&nbsp;calls.&nbsp;There&nbsp;has&nbsp;recently&nbsp;been&nbsp;some&nbsp;progress&nbsp;on&nbsp;<br />
implementing&nbsp;kernel&nbsp;threads&nbsp;in&nbsp;Linux&nbsp;1.3&nbsp;using&nbsp;the&nbsp;clone()&nbsp;system&nbsp;<br />
call.&nbsp;Adding&nbsp;priority&nbsp;I/O&nbsp;to&nbsp;Linux&nbsp;might&nbsp;be&nbsp;a&nbsp;more&nbsp;complicated&nbsp;job,&nbsp;<br />
because&nbsp;many&nbsp;device&nbsp;drivers&nbsp;would&nbsp;have&nbsp;to&nbsp;be&nbsp;extended&nbsp;by&nbsp;priority&nbsp;wait&nbsp;<br />
queues.&nbsp;<br />
Implemented&nbsp;options&nbsp;<br />
-------------------&nbsp;<br />
As&nbsp;POSIX.1b&nbsp;conformance&nbsp;does&nbsp;not&nbsp;require&nbsp;the&nbsp;implementation&nbsp;of&nbsp;all&nbsp;<br />
these&nbsp;functions,&nbsp;macros&nbsp;have&nbsp;been&nbsp;specified&nbsp;for&nbsp;&lt;unistd.h&gt;&nbsp;that&nbsp;<br />
indicate&nbsp;to&nbsp;application&nbsp;software&nbsp;which&nbsp;of&nbsp;the&nbsp;POSIX.1b&nbsp;functionality&nbsp;<br />
is&nbsp;available&nbsp;on&nbsp;this&nbsp;system.&nbsp;This&nbsp;way,&nbsp;portable&nbsp;software&nbsp;can&nbsp;be&nbsp;<br />
written&nbsp;that&nbsp;uses&nbsp;real-time&nbsp;features&nbsp;only&nbsp;when&nbsp;they&nbsp;are&nbsp;available.&nbsp;<br />
Under&nbsp;the&nbsp;latest&nbsp;Linux&nbsp;kernel&nbsp;and&nbsp;libc&nbsp;development&nbsp;versions,&nbsp;the&nbsp;<br />
following&nbsp;POSIX.1b&nbsp;macros&nbsp;have&nbsp;been&nbsp;defined&nbsp;and&nbsp;indicate&nbsp;implemented&nbsp;<br />
functions:&nbsp;<br />
_POSIX_FSYNC&nbsp;<br />
_POSIX_MAPPED_FILES&nbsp;<br />
_POSIX_MEMLOCK&nbsp;<br />
_POSIX_MEMLOCK_RANGE&nbsp;<br />
_POSIX_MEMORY_PROTECTION&nbsp;<br />
_POSIX_PRIORITY_SCHEDULING&nbsp;<br />
The&nbsp;POSIX.1b&nbsp;options&nbsp;indicated&nbsp;by&nbsp;the&nbsp;following&nbsp;macros&nbsp;have&nbsp;not&nbsp;yet&nbsp;<br />
been&nbsp;implemented&nbsp;under&nbsp;Linux:&nbsp;<br />
_POSIX_ASYNCHRONOUS_IO&nbsp;<br />
_POSIX_MESSAGE_PASSING&nbsp;<br />
_POSIX_PRIORITIZED_IO&nbsp;<br />
_POSIX_REALTIME_SIGNALS&nbsp;<br />
_POSIX_SEMAPHORES&nbsp;<br />
_POSIX_SHARED_MEMORY_OBJECTS&nbsp;<br />
_POSIX_SYNCHRONIZED_IO&nbsp;<br />
_POSIX_TIMERS&nbsp;<br />
General&nbsp;real-time&nbsp;problems&nbsp;<br />
--------------------------&nbsp;<br />
Apart&nbsp;from&nbsp;implementing&nbsp;new&nbsp;POSIX.1b&nbsp;system&nbsp;calls,&nbsp;there&nbsp;are&nbsp;a&nbsp;number&nbsp;<br />
of&nbsp;other&nbsp;problems&nbsp;with&nbsp;the&nbsp;current&nbsp;Linux&nbsp;kernel&nbsp;that&nbsp;have&nbsp;to&nbsp;be&nbsp;solved&nbsp;<br />
in&nbsp;order&nbsp;to&nbsp;improve&nbsp;real-time&nbsp;performance.&nbsp;<br />
Problem&nbsp;1:&nbsp;Interrupt&nbsp;dispatch&nbsp;latency&nbsp;<br />
A&nbsp;blocked&nbsp;process&nbsp;waiting&nbsp;for&nbsp;the&nbsp;end&nbsp;of&nbsp;some&nbsp;I/O&nbsp;request&nbsp;becomes&nbsp;<br />
runnable&nbsp;again&nbsp;when&nbsp;the&nbsp;CPU&nbsp;receives&nbsp;an&nbsp;interrupt&nbsp;from&nbsp;the&nbsp;I/O&nbsp;device&nbsp;<br />
that&nbsp;processed&nbsp;the&nbsp;request.&nbsp;The&nbsp;time&nbsp;that&nbsp;passes&nbsp;between&nbsp;the&nbsp;interrupt&nbsp;<br />
and&nbsp;the&nbsp;execution&nbsp;of&nbsp;the&nbsp;interrupt&nbsp;handler&nbsp;is&nbsp;called&nbsp;the&nbsp;&quot;interrupt&nbsp;<br />
latency&quot;.&nbsp;The&nbsp;time&nbsp;that&nbsp;passes&nbsp;between&nbsp;the&nbsp;interrupt&nbsp;and&nbsp;the&nbsp;<br />
continuation&nbsp;of&nbsp;the&nbsp;execution&nbsp;of&nbsp;the&nbsp;blocked&nbsp;process&nbsp;is&nbsp;called&nbsp;the&nbsp;<br />
&quot;interrupt&nbsp;dispatch&nbsp;latency&quot;.&nbsp;We&nbsp;are&nbsp;assuming&nbsp;that&nbsp;the&nbsp;blocked&nbsp;process&nbsp;<br />
is&nbsp;the&nbsp;process&nbsp;with&nbsp;the&nbsp;highest&nbsp;priority&nbsp;(the&nbsp;POSIX.1b&nbsp;scheduler&nbsp;<br />
system&nbsp;calls&nbsp;allow&nbsp;to&nbsp;ensure&nbsp;this).&nbsp;Many&nbsp;real-time&nbsp;applications&nbsp;<br />
require&nbsp;that&nbsp;the&nbsp;interrupt&nbsp;dispatch&nbsp;latency&nbsp;is&nbsp;as&nbsp;short&nbsp;as&nbsp;possible,&nbsp;<br />
some&nbsp;applications&nbsp;require&nbsp;even&nbsp;guarantees&nbsp;for&nbsp;the&nbsp;maximum&nbsp;interrupt&nbsp;<br />
dispatch&nbsp;latency&nbsp;(e.g.&nbsp;20&nbsp;microseconds).&nbsp;<br />
At&nbsp;the&nbsp;moment,&nbsp;Linux&nbsp;has&nbsp;basically&nbsp;two&nbsp;types&nbsp;of&nbsp;interrupt&nbsp;handlers:&nbsp;<br />
&quot;fast&quot;&nbsp;and&nbsp;&quot;slow&quot;&nbsp;ones.&nbsp;<br />
The&nbsp;&quot;slow&nbsp;interrupt&nbsp;handlers&quot;&nbsp;call&nbsp;the&nbsp;scheduler&nbsp;each&nbsp;time&nbsp;immediately&nbsp;<br />
after&nbsp;the&nbsp;interrupt&nbsp;has&nbsp;been&nbsp;handled.&nbsp;This&nbsp;guarantees&nbsp;that&nbsp;if&nbsp;the&nbsp;<br />
process&nbsp;has&nbsp;become&nbsp;runnable&nbsp;by&nbsp;handling&nbsp;the&nbsp;interrupt&nbsp;and&nbsp;has&nbsp;the&nbsp;<br />
highest&nbsp;priority,&nbsp;then&nbsp;it&nbsp;will&nbsp;directly&nbsp;get&nbsp;control&nbsp;over&nbsp;the&nbsp;CPU&nbsp;after&nbsp;<br />
the&nbsp;interrupt&nbsp;handler.&nbsp;This&nbsp;ensures&nbsp;a&nbsp;short&nbsp;interrupt&nbsp;dispatch&nbsp;<br />
latency,&nbsp;but&nbsp;the&nbsp;cost&nbsp;is&nbsp;that&nbsp;the&nbsp;scheduler&nbsp;is&nbsp;executed&nbsp;for&nbsp;each&nbsp;<br />
interrupt,&nbsp;which&nbsp;can&nbsp;cause&nbsp;a&nbsp;system&nbsp;performance&nbsp;degradation&nbsp;for&nbsp;<br />
devices&nbsp;with&nbsp;a&nbsp;high&nbsp;interrupt&nbsp;rate&nbsp;(e.g.,&nbsp;network&nbsp;controllers).&nbsp;The&nbsp;<br />
slow&nbsp;interrupt&nbsp;handler&nbsp;do&nbsp;not&nbsp;disable&nbsp;other&nbsp;interrupts&nbsp;while&nbsp;they&nbsp;are&nbsp;<br />
being&nbsp;executed.&nbsp;This&nbsp;ensures&nbsp;a&nbsp;low&nbsp;interrupt&nbsp;latency,&nbsp;because&nbsp;other&nbsp;<br />
higher&nbsp;priority&nbsp;interrupts&nbsp;will&nbsp;not&nbsp;be&nbsp;blocked.&nbsp;The&nbsp;&quot;slow&quot;&nbsp;interrupt&nbsp;<br />
handler&nbsp;behavior&nbsp;is&nbsp;what&nbsp;you&nbsp;want&nbsp;for&nbsp;real-time&nbsp;applications.&nbsp;<br />
The&nbsp;&quot;fast&nbsp;interrupt&nbsp;handlers&quot;&nbsp;only&nbsp;mark&nbsp;in&nbsp;a&nbsp;bitmask&nbsp;that&nbsp;an&nbsp;interrupt&nbsp;<br />
has&nbsp;been&nbsp;handled&nbsp;for&nbsp;this&nbsp;device.&nbsp;The&nbsp;scheduler&nbsp;is&nbsp;NOT&nbsp;called&nbsp;after&nbsp;<br />
the&nbsp;fast&nbsp;interrupt&nbsp;handler&nbsp;and&nbsp;the&nbsp;process&nbsp;waiting&nbsp;on&nbsp;the&nbsp;interrupt&nbsp;<br />
may&nbsp;have&nbsp;to&nbsp;wait&nbsp;up&nbsp;to&nbsp;1&nbsp;s&nbsp;/&nbsp;HZ&nbsp;=&nbsp;10&nbsp;ms&nbsp;for&nbsp;the&nbsp;next&nbsp;timer&nbsp;interrupt&nbsp;<br />
which&nbsp;will&nbsp;call&nbsp;the&nbsp;scheduler&nbsp;again&nbsp;(because&nbsp;the&nbsp;timer&nbsp;interrupt&nbsp;is&nbsp;<br />
handled&nbsp;the&nbsp;&quot;slow&quot;&nbsp;way).&nbsp;&quot;Fast&quot;&nbsp;interrupt&nbsp;handlers&nbsp;are&nbsp;those&nbsp;which&nbsp;are&nbsp;<br />
installed&nbsp;by&nbsp;the&nbsp;driver&nbsp;by&nbsp;specifying&nbsp;the&nbsp;SA_INTERRUPT&nbsp;option&nbsp;when&nbsp;<br />
calling&nbsp;request_irq().&nbsp;&quot;Fast&quot;&nbsp;interrupt&nbsp;handlers&nbsp;are&nbsp;the&nbsp;reason&nbsp;why&nbsp;<br />
for&nbsp;devices&nbsp;like&nbsp;the&nbsp;serial&nbsp;port,&nbsp;the&nbsp;interrupt&nbsp;dispatch&nbsp;latency&nbsp;can&nbsp;<br />
easily&nbsp;reach&nbsp;10&nbsp;ms&nbsp;and&nbsp;more.&nbsp;&quot;Fast&quot;&nbsp;interrupt&nbsp;handlers&nbsp;disable&nbsp;other&nbsp;<br />
interrupts&nbsp;while&nbsp;the&nbsp;handler&nbsp;is&nbsp;being&nbsp;executed.&nbsp;This&nbsp;increases&nbsp;<br />
interrupt&nbsp;latency.&nbsp;The&nbsp;Linux&nbsp;&quot;fast&quot;&nbsp;interrupt&nbsp;handlers&nbsp;cause&nbsp;very&nbsp;low&nbsp;<br />
interrupt&nbsp;handling&nbsp;overhead,&nbsp;but&nbsp;they&nbsp;can&nbsp;be&nbsp;the&nbsp;cause&nbsp;for&nbsp;a&nbsp;lot&nbsp;of&nbsp;<br />
headaches&nbsp;for&nbsp;real-time&nbsp;application&nbsp;developers.&nbsp;<br />
See&nbsp;linux/arch/i386/kernel/irq.c,&nbsp;linux/include/asm-i386/irq.h&nbsp;and&nbsp;<br />
linux/arch/i386/kernel/entry.S&nbsp;for&nbsp;implementation&nbsp;details&nbsp;of&nbsp;how&nbsp;fast&nbsp;<br />
and&nbsp;slow&nbsp;interrupts&nbsp;are&nbsp;handled&nbsp;in&nbsp;Linux.&nbsp;<br />
Examples&nbsp;for&nbsp;&quot;slow&quot;&nbsp;Linux&nbsp;1.3&nbsp;interrupt&nbsp;drivers&nbsp;with&nbsp;good&nbsp;interrupt&nbsp;<br />
dispatch&nbsp;latency&nbsp;are&nbsp;<br />
keyboard&nbsp;<br />
floppy&nbsp;disk&nbsp;<br />
timer&nbsp;<br />
sound&nbsp;cards&nbsp;<br />
mouse&nbsp;drivers&nbsp;<br />
some&nbsp;Ethernet&nbsp;cards&nbsp;<br />
Examples&nbsp;for&nbsp;&quot;fast&quot;&nbsp;interrupt&nbsp;drivers&nbsp;with&nbsp;bad&nbsp;interrupt&nbsp;dispatch&nbsp;<br />
latency&nbsp;are&nbsp;<br />