Eric Noulard wrote:
> 2007/5/15, Gilles Chanteperdrix <[EMAIL PROTECTED]>:
> > Daniel Schnell wrote:
> > > The reason I was looking at the memcpy native performance was because I
> > found Xenomai Posix message queues somewhat slow:
> > > In two tasks where one is receiving a 32 kBytes msg and the other
> > sending to this task 32 kbytes of data, I have an average cycle time of
> > more than 1 ms.
> > > Looking at the memcpy performance of my system tells me something:
> > > Memcpy(32 KB) -> 400 us
> > > Two msg_send(32KB) cannot be less than 2x400 us + 2 ctx switch away,
> > probably even more because we have to write first to Kernel memory, then
> > the ctx switch, then copying from Kernel memory to user buffer, than ctx
> > switch. This simply means I cannot use msg queues for anything bigger than
> > 1K, which means I have to use shared memory for that.
>
> Are your 2 tasks in user-space or 1 in user 1 in kernel?
>
> > so it is probably better to use message queues to pass pointers to a
> > shared memory region, allowing zero copies.
>
> I was about to say just the same but before developing my idea
> I have xenomai question:
> Are the share memory region obtained by shm_open
> shareable between kernel task and user task just like
> rt_heap_create/rt_heap_alloc does (read from the doc).
Well, if you found rt_heaps doc, it would have been easy to have a look
at posix shared memory doc as well... Anyway, yes, on platforms where
sharing a memory area between kernel space and user-space is not a
problem, posix shared memory are shareable. On ARM, it is a no go
because of the cache architecture.
--
Gilles Chanteperdrix.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
