Allocating large shared memory blocks jeopardize real-time?

QNX Newsgroups (Archives) qdn.public.qnxrtp.os
#1

Here is my situation. I have a hardware timer board that creates periodic
interrupts at 1KHz. My ISR only sends a pulse to my timer task. The timer
task runs at highest priority and waits for pulses. Once it got a pulse, it
increases a counter and checks if there are more pulses in the queue. If
yes, it aborts because that means it couldn’t keep up with the 1KHz timing.

This works perfect on QNX4, I never had the timer falling behind. It worked
pretty stable on QNX6, but there was a problem, and now I found which it
is…

If I allocate a large shared memory block (>70Meg) from a normal (priority
10) task, the timer task immediately falls behind. It looks like that the
kernel is busy with creating the shmem and doesn’t let the timer task
execute (???). How can this be…
I create the shared memory with shmem_create(…, O_RDWR | O_CREAT | O_EXCL,
S_IRWXU | S_IRWXG | NS_IRWXO), do a ftruncate, then a mmap(…, …, PROT_READ
| PROT_WRITE, MAP_SHARED, …)

On QNX4, I don’t have this problem.

Any input welcome, this is a vital problem to my application…
Markus

#2

with qnx6 the latencies thru the kernel and drivers are better than in qnx4.
on my p350 i see a worst case interrupt chain in a busy system of ~20
microseconds ( chain = irqs 12 (ps2 mouse), 14 (disk), 0 (timer tick)

so what you say surprises me. maybe we need to see your isr code and
anything else you have. the procnto thread doing the malloc for you is
completely independent of your other thread and will run at the priority
of the client app.
and your own isr and timer thread are not malloc’ing so they should not
hit any contention in the kernel.

we’d need to see more to determine what is going on there…

Markus Loffler <loffler@ces.clemson.edu> wrote:

Here is my situation. I have a hardware timer board that creates periodic
interrupts at 1KHz. My ISR only sends a pulse to my timer task. The timer
task runs at highest priority and waits for pulses. Once it got a pulse, it
increases a counter and checks if there are more pulses in the queue. If
yes, it aborts because that means it couldn’t keep up with the 1KHz timing.

This works perfect on QNX4, I never had the timer falling behind. It worked
pretty stable on QNX6, but there was a problem, and now I found which it
is…

If I allocate a large shared memory block (>70Meg) from a normal (priority
10) task, the timer task immediately falls behind. It looks like that the
kernel is busy with creating the shmem and doesn’t let the timer task
execute (???). How can this be…
I create the shared memory with shmem_create(…, O_RDWR | O_CREAT | O_EXCL,
S_IRWXU | S_IRWXG | NS_IRWXO), do a ftruncate, then a mmap(…, …, PROT_READ
| PROT_WRITE, MAP_SHARED, …)

On QNX4, I don’t have this problem.

Any input welcome, this is a vital problem to my application…
Markus

–
Randy Martin randy@qnx.com
Manager of FAE Group, North America
QNX Software Systems www.qnx.com
175 Terence Matthews Crescent, Kanata, Ontario, Canada K2M 1W8
Tel: 613-591-0931 Fax: 613-591-3579