Fedora and cpu usage
bob 295
icanprogram-sKcZck+fQKg at public.gmane.org
Fri Jul 31 14:43:57 UTC 2009
I'm running stock Fedora 10 along with an A-D card which is interrupt driven.
The card is configured so that the interrupts are occurring every 8msec as
determined by an external clock.
Here is a snip from some tracing info written to a file:
=========== begin snip =========
delta_usec[1719] = 8346 toTrigger =78 toFileMgr=348
delta_usec[1720] = 8324 toTrigger =59 toFileMgr=314
delta_usec[1721] = 8323 toTrigger =42 toFileMgr=296
delta_usec[1724] = 24991 toTrigger =891 toFileMgr=1125
delta_usec[1724] = 0 toTrigger =6042 toFileMgr=6318
delta_usec[1724] = 0 toTrigger =7328 toFileMgr=7715
delta_usec[1725] = 8470 toTrigger =1691 toFileMgr=1916
delta_usec[1726] = 8218 toTrigger =55 toFileMgr=305
delta_usec[1727] = 8354 toTrigger =44 toFileMgr=299
=========== end snip ============
The first delta_usec refers to the inter interrupt spacing. The item in the
[] is the interrupt sequence number. The toTrigger and toFileMgr refer to
timing points further into the multiple process application.
The question is what could have happened to the Linux system (otherwise not
used for any other purpose than this test) in and around seq number 1721.
The interrupts 1722 and 1723 still happened otherwise the sequence number
would not have incremented to 1724. The repeated 1724 is a result of an
overwrite on some global variables. In reality they are the triggers for
1722 and 1723. Similarly the 0 is an artifact because our trace timing
variable also was overwritten. The 24991 usec lag is real and is about
right for those extra clock ticks ... although there is no real way to know
if they happened at 8msec intervals.
What appears to have happened is all was ticking along smoothly with the Linux
kernel servicing the interrupt every 8msec or so and handing it off to the
application, who then handled things within 300usec or so. All of sudden,
with the kernel still handling the interrupts on time, the rest of the Linux
system became very busy for over 25msec.
This is Fedora 10 running on a 1GHz processor. The Linux box is on a
dedicated network with one other node and is otherwise not running any other
applications other than KDE while this test is performed.
Any thoughts on what could be causing this? Is it something to do with the
file system writing that trace file? There doesn't appear to be any
correlation to these outliers and the scheduled cron jobs like log rotate.
I'm trying to avoid the complication of adding the RTAI real time Linux patch.
Thanks in advance.
bob
--
The Toronto Linux Users Group. Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists
More information about the Legacy
mailing list