While working on an embedded Linux project I came across a strange
problem.
My platform is a 500MHz Geode based PC-104 running the preemption
options of the 2.6.13 kernel. The platform is diskless (no swap) with
256MB. The system timer is set to 1 KHz.
I have an application that uses a number of tasklets which respond to
a 100Hz interrupt. Normally these tasklets finish in about 600uSec or
so.
I recently upped the memory to 1GB and now the tasklets will miss the
100Hz interrupt on occasion. The only change has been the added
memory (problem goes away when I put the 256MB back in).
Here is the strange part:
According to my internal counter and the jiffies counter. The
'dropped' tasklets occur on _exactly_ 10 minute boundaries (600,000
jiffies). Never one less or one more, always 600k.
I tried running my tasklets with tasklet_hi_schedule() which should
put them above timers and ethernet but observe no changes. Whatever
is delaying my tasklets is blocking about 8 milliseconds of cpu every
10 minutes.
I see no network activity (ifconfig Rx and Tx byte counters).
Given that '10 minutes' seems more of a human tuneable number than
something binary, I looked into the pdflush daemon but all of its
parameters are down in the sub-10 second range
(the only daemon I could think of that deals with memory)
I've cleared out all the cron jobs and even killed crond, no changes.
Anyone have any ideas of what apparently un-preemptable process eats
cpu time exactly every 10 minutes? It seems to be memory related
since that is what invoked the problem, but any cache or garbage
collection should be relatively tame.
Thanks
-Bruce
--
To unsubscribe from this list: send an email with
"unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx
Please read the FAQ at http://kernelnewbies.org/FAQ
