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:mskuhn@cip.informatik.uni-erlangen.de>).">mskuhn@cip.informatik.uni-erlangen.de>).</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:carlson@dot4.com>">carlson@dot4.com></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 />