Fedora and cpu usage

[Lennart Sorensen]

On Fri, Jul 31, 2009 at 10:43:57AM -0400, bob 295 wrote:
> 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.

Does the system have any SMM (system management mode) stuff?

-- 
Len Sorensen
--
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