From: Gilles Chanteperdrix <gilles.chanteperdrix@xenomai.org>
To: Wolfgang Grandegger <wg@domain.hid>
Cc: xenomai-help <xenomai@xenomai.org>
Subject: Re: [Xenomai-help] Mode switch when using RT heap on ARM
Date: Fri, 14 Nov 2008 10:45:12 +0100 [thread overview]
Message-ID: <491D48A8.20303@domain.hid> (raw)
In-Reply-To: <491D4910.6030707@domain.hid>
Wolfgang Grandegger wrote:
> Gilles Chanteperdrix wrote:
>> Wolfgang Grandegger wrote:
>>> Gilles Chanteperdrix wrote:
>>>> Wolfgang Grandegger wrote:
>>>>> Hello,
>>>>>
>>>>> I realized that accessing memory allocated with rt_heap_alloc() causes
>>>>> mode switches on ARM i.mx31. The attached patch provides a demo program
>>>>> to demonstrate the problem, which actually does *not* show up on my
>>>>> PowerPC TQM5200 board.
>>>> Index: xenomai-2.4.x/examples/native/rtheap.c
>>>> ===================================================================
>>>> --- /dev/null
>>>> +++ xenomai-2.4.x/examples/native/rtheap.c
>>>> @@ -0,0 +1,164 @@
>>>> +#include <stdio.h>
>>>> +#include <signal.h>
>>>> +#include <unistd.h>
>>>> +#include <sys/mman.h>
>>>> +
>>>> +#include <native/task.h>
>>>> +#include <native/timer.h>
>>>> +#include <native/heap.h>
>>>> +
>>>> +#define USE_HEAP
>>>> +//#define USE_SIGXCPU
>>>> +
>>>> +#define HEAP_SIZE (1024*1024)
>>>> +#define HEAP_MODE 0 /* Local heap. */
>>>> +
>>>> +RT_HEAP heap_desc;
>>>> +RT_TASK demo_task;
>>>> +
>>>> +
>>>> +static int block_sizes[] = {16, 20, 90, 150, 310, 800, 1000};
>>>> +
>>>> +/* NOTE: error handling omitted. */
>>>> +
>>>> +void demo(void *arg)
>>>> +{
>>>> + RTIME now, previous;
>>>> + void *block;
>>>> + int sizes = sizeof(block_sizes) / sizeof(int);
>>>> + int count = 0;
>>>> + int size, err;
>>>> + int *ptr;
>>>> +
>>>> +#ifdef USE_SIGXCPU
>>>> + /* Ask Xenomai to warn us upon switches to secondary mode. */
>>>> + rt_task_set_mode(0, T_WARNSW, NULL);
>>>> +#endif
>>>> +
>>>> + /*
>>>> + * Arguments: &task (NULL=self),
>>>> + * start time,
>>>> + * period (here: 1 s)
>>>> + */
>>>> + rt_task_set_periodic(NULL, TM_NOW, 10000000);
>>>> + previous = rt_timer_read();
>>>> +
>>>> + while (1) {
>>>> + rt_task_wait_period(NULL);
>>>> + now = rt_timer_read();
>>>> +
>>>> + size = block_sizes[count % sizes];
>>>> +#ifdef USE_HEAP
>>>> + /*
>>>> + * Request a 16-bytes block, asking for a non-blocking call
>>>> + * since only Xenomai tasks may block.
>>>> + */
>>>> + err = rt_heap_alloc(&heap_desc, size, TM_NONBLOCK, &block);
>>>> + if (err) {
>>>> + printf("rt_heap_alloc() failed with %d\n", err);
>>>> + break;
>>>> + }
>>>> +
>>>> + ptr = (int *)block;
>>>> + *ptr = 0xdeadbeef;
>>>> + if (*ptr != 0xdeadbeef) {
>>>> + printf("Write/read test to heap failed\n");
>>>> + break;
>>>> + }
>>>> +
>>>> + ptr = (int *)(block + size - sizeof(int));
>>>>
>>>> This is not guaranteed to be aligned on an int. Could you try:
>>>>
>>>> ptr = (int *)(((unsigned long) block + size - sizeof(int)) & ~3);
>>> With aligned accesses rtheap reports just3 mode switches in both modes,
>>> 0 and H_NONCACHED. But already one mode switch is too much!
>> I hope we get several mode switches because the allocator returns
>> different pages. To workaround this, we will have to cause a fault on
>> each page. We can do this either in kernel or user-space.
I checked this, and this is true: we get a fault by different page
returned by the allocator.
>
> Doing it in kernel-space, e.g. in xnheap_init_mapped(), does not help.
> Anyhow, I think the memory pages get touched in kernel space already here:
That is because you have to fault the user-space addresses, not the
kernel-space addresses, you have to use something like handle_mm_fault.
>
> http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/nucleus/heap.c#096
>
> But the mode switches disappear when I touch the allocated memory (read
> and write back) in __map_heap_memory() write after the __real_mmap(:
>
> http://www.rts.uni-hannover.de/xenomai/lxr/source/src/skins/native/heap.c#031
The problem if we do it in user-space is that we would have to do this
for every uses of the heaps, that is native skin heaps, posix skin
heaps, mutexes heaps, and every rtdm driver using shared heaps too.
--
Gilles.
next prev parent reply other threads:[~2008-11-14 9:45 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-10 9:58 [Xenomai-help] Mode switch when using RT heap on ARM Wolfgang Grandegger
2008-11-10 11:42 ` Gilles Chanteperdrix
2008-11-10 12:32 ` Wolfgang Grandegger
2008-11-10 12:35 ` Wolfgang Grandegger
[not found] ` <c54f288fee2b8a5ee68a00c27056c6ed.squirrel@domain.hid>
2008-11-10 18:55 ` Wolfgang Grandegger
2008-11-10 19:02 ` Gilles Chanteperdrix
2008-11-10 20:05 ` Wolfgang Grandegger
2008-11-11 22:46 ` Gilles Chanteperdrix
2008-11-12 8:55 ` Wolfgang Grandegger
2008-11-12 9:12 ` Philippe Gerum
2008-11-12 10:24 ` Gilles Chanteperdrix
2008-11-12 10:50 ` Wolfgang Grandegger
2008-11-12 11:12 ` Philippe Gerum
2008-11-12 11:20 ` Wolfgang Grandegger
2008-11-13 17:57 ` Gilles Chanteperdrix
2008-11-13 18:27 ` Wolfgang Grandegger
2008-11-13 18:23 ` Gilles Chanteperdrix
2008-11-13 18:39 ` Wolfgang Grandegger
2008-11-13 18:15 ` Gilles Chanteperdrix
2008-11-13 20:15 ` Wolfgang Grandegger
2008-11-14 8:22 ` Gilles Chanteperdrix
2008-11-14 9:46 ` Wolfgang Grandegger
2008-11-14 9:45 ` Gilles Chanteperdrix [this message]
2008-11-17 13:41 ` Gilles Chanteperdrix
-- strict thread matches above, loose matches on Subject: below --
2008-11-11 11:24 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=491D48A8.20303@domain.hid \
--to=gilles.chanteperdrix@xenomai.org \
--cc=wg@domain.hid \
--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.