lkml.org 
[lkml]   [1996]   [Aug]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectSCHED_FIFO: sleep times longer than expected (2nd post)

Hi there,
can some of the kernel experts give some advice or comment about the
following observation:

o A device driver I am writing for a data acquisition board is used by a
process with SCHED_FIFO policy, priority 1.
o All other processes on the machine are SCHED_OTHER.
o A timer makes sure that the process gets a wake_up on *EVERY* clock
tick, i.e. the driver installs (and reinstalls all the time) a timer
which expires at jiffies+1.
o Every once in a while the driver sleeps the calling process with
interruptible_sleep_on.

Now the problem:
Every once in a while I measure sleep times much bigger than 0.060s
(6jiffies, measured with do_gettimeofday) although I thought I
understood the scheduling enough to predict at most sleep times
of 0.020s, with an average less than 0.010s. What I thought is that
with the above setup, the SCHED_OTHER processes may consume only the
rest of a jiffy after the SCHED_FIFO process calls
interruptible_sleep_on.

Can anybody tell me what is wrong here? Is the system trapped in "bad"
device drivers consuming much more cpu time in a row than one jiffy? Is
there an "easy" way of tracking down the bad guys?

My setup is
kernel 2.0.7
i486 with 33 BogoMips
64 MBytes of memory (no swapping anytime!!!, guaranteed)


IF POSSIBLE ANSWER
BY EMAIL TO
---------------> kir@iitb.fhg.de
BECAUSE I AM NOT SUBSCRIBED
TO THIS GROUP
(otherwise I'll find your answer in the archive.)

Thanks for you help,
Harald Kirsch

(P.S.: This is my second attempt to put this into the mailing-list.)
-------------------------------------------------+------------------
Harald Kirsch, kir@iitb.fhg.de, +49 721 6091 384 | This message is
FhG/IITB, Fraunhoferstr.1, 76131 Karlsruhe | subject oriented.

\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.039 / U:1.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site