From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Philippe Gerum <rpm@xenomai.org>
Cc: xenomai@xenomai.org, Bob Feretich <bob.feretich@domain.hid>
Subject: Re: [Xenomai-help] Shared memory between a Xenomai user task and a standard Linux process?
Date: Mon, 02 Aug 2010 19:56:57 +0200 [thread overview]
Message-ID: <4C5706E9.50101@domain.hid> (raw)
In-Reply-To: <1280770720.6700.82.camel@domain.hid>
Philippe Gerum wrote:
> On Mon, 2010-08-02 at 08:01 +0200, Gilles Chanteperdrix wrote:
>> Due to their limitations on ARM platform (they are uncached on pre-v6
>> ARMs), RT_HEAP should more be reserved to communications between
>> user-space tasks and kernel-space tasks on these platforms. For
>> communications between two user-space processes, using plain Linux
>> shared memories is recommended.
>>
>
> ARM VIVT caching kills common sense. Note that in the particular case of
> a rt / non-rt communication, standard shm would imply priority inversion
> induced by heavyweight synchronization between rt senders and non-rt
> receivers, so that would not fly that well. This is still possible to
> use a lockless approach to queue data though. YMMV.
Well, in fact, with the native API, you have the choice to use cached or
non-cached heaps. So, if you know the heap will be used only by
user-space applications, you can keep the heap cached, and forgot what I
said. And Bob uses an OMAP3 anyway if I am not mistaken, so he has a
shiny VIPT cache.
--
Gilles.
next prev parent reply other threads:[~2010-08-02 17:56 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-08-02 2:06 [Xenomai-help] Shared memory between a Xenomai user task and a standard Linux process? Bob Feretich
2010-08-02 5:42 ` Philippe Gerum
2010-08-02 6:01 ` Gilles Chanteperdrix
2010-08-02 17:38 ` Philippe Gerum
2010-08-02 17:56 ` Gilles Chanteperdrix [this message]
2010-08-02 20:52 ` Bob Feretich
2010-08-02 21:52 ` Gilles Chanteperdrix
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4C5706E9.50101@domain.hid \
--to=gilles.chanteperdrix@xenomai.org \
--cc=bob.feretich@domain.hid \
--cc=rpm@xenomai.org \
--cc=xenomai@xenomai.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.