[Xenomai-help] gatekeeper using 90% CPU...

[Xenomai-help] gatekeeper using 90% CPU...

[Eric Eric]

[-- Attachment #1: Type: text/plain, Size: 2197 bytes --]

Hi, I've added several benchmarks to the benchmark suite and seem to have a
problem with some of them causing the gatekeeper process to show high cpu
load.  A few things -don't- cause this problem.  The first is the standard
benchmarks shipped with Xenomai.  Another example of something that doesn't
peg gatekeeper is a synthetic workload I added that spawns a Xenomai kernel
thread that spins for a certain period then sleeps for a certain period,
cycling until terminated (an example of these periods may be spin fpr 800mS
sleep for 200mS).  What -does- seem to be causing this problem is another
benchmark I added that spawns a producer and consumer thread, with the
consumer waiting on a semaphore and the producer incrementing the
semaphore.  I suspect a cause for the excessive gatekeeper usage may be the
way I've structured the benchmark.  The user-mode program starts a
real-time user-mode thread that runs in a loop and does a real-time
initialization ioctl to create two POSIX threads (I originally had this as
a nrt ioctl but made it rt to avoid a mode switch).  Both threads wait on a
semaphore, then the user-mode thread does another real-time ioctl to cause
the module to broadcast on the semaphore and wake both kernel threads.  The
ioctl then blocks on a pthread_join while the producer and consumer threads
do 100,000 iterations (takes about a second or two on my hardware).  The
user mode program then prints the results to date, loops back around and
restarts the process.  My suspicion is that this act of starting and
stopping of the kernel threads may be causing the CPU utilization with
gatekeeper.  What do you think?  Also, I have registered a handler for
SIGXCPU and seem to see no mode switches at all, which seems strange
considering /proc/xenomai/stat indicates MSW is occuring.

/proc/xenomai/stat shows about double the number of mode switches for my
benchmark versus in-kernel periodic task.  While this may not be optimal,
it doesn't seem like it should bring gatekeeper from 1% CPU to 90% CPU
usage.  My system is a beagleboard XM running Xenomai 2.6.0 with the TI
2.6.37 kernel with beagle board patches applied.

As always, thanks for any assistance.

- Eric

[-- Attachment #2: Type: text/html, Size: 2244 bytes --]

Re: [Xenomai-help] gatekeeper using 90% CPU...

[Gilles Chanteperdrix]

On 01/17/2012 02:14 AM, Eric Eric wrote:
> (snip)
> /proc/xenomai/stat shows about double the number of mode switches for my
> benchmark versus in-kernel periodic task.  While this may not be optimal,
> it doesn't seem like it should bring gatekeeper from 1% CPU to 90% CPU
> usage.  My system is a beagleboard XM running Xenomai 2.6.0 with the TI
> 2.6.37 kernel with beagle board patches applied.
> 
> As always, thanks for any assistance.

Show us the source. Also note that spinning in primary mode more than
10ms is a bad idea, as the linux kernel will then try to catch up with
the lost ticks. gatekeeper activity is normally the sign of mode
switches. As for the mode switches detection, check
examples/native/sigdebug.c.

-- 
                                                                Gilles.