Jan Kiszka wrote:
Wolfgang Grandegger wrote:
[EMAIL PROTECTED] wrote:
memset should work with Xenomai heaps, I suspect your problem is
rather that the memory is not really allocated until you memset it,
which fails when no memory is available. In this case, calling memset
on memory allocated with malloc should segfault the same way when the
system memory is exhausted. IIRC, this behaviour is documented in
mlockall manual page.

Mr. Denk told me about this strange (for RTOSs) behaviour of the Linux
kernel. Therefore I used the Xenomai heap mechanism, expecting
allocated memory is allocated at once not some time later (why do I
allocate memory otherwise : to be shure memory is available).
Does Xenomai use the Linux allocation mechanism ??


Be careful with sysconf(_SC_AVPHYS_PAGES), it may include the swap
size, but when mlocking memory, your application can not use swap
pages, so, you should substract the size of swap, if any.
Also, what is the value of /proc/sys/vm/overcommit_memory on your
system ?

Our System does not have a swap device\space.
/proc/sys/vm/overcommit_memory = 0
(whatever this means)
I gave your program a try on my MPC5200 and got the following output
(after some corrections):

bash-2.05b# ./heap2
Start Heap
root_thread_init :
timer startedt
display task created
root_thread_init beendet
Available Memory 56238080 (Pagesize 4096)
heap 0 of size 16000000 created
Heap 0 allocated size 16000000
heap 1 of size 16000000 created
Heap 1 allocated size 16000000
heap 2 of size 16000000 created
Heap 2 allocated size 16000000
__alloc_pages: 0-order allocation failed (gfp=0x1f2/0)
Available Memory after allocation 8933376
__alloc_pages: 0-order allocation failed (gfp=0x1f0/0)
Heap 3 created with size 4218880
Heap 3 allocated size 4218880
Memory allocated in total : 52218880
Segmentation fault

The are some long delays (approx. 40 secs) around __alloc_pages. Finally
it crashes in memset. With the attached xenomai patch, which touches the
reserved page once, memset works fine. Let's wait what Philippe says. I
remember that the "touch" was needed for RTAI shared memory as well.

What is the difference between touching the page in kernel space and in
user space? Is there no risk that the kernel will oops then at some
point? Do we get the same result when touching the heap pages in user
space immediately after rt_help_alloc'ing them? Roderik's demo allocates
first and then touches/memsets. [I have no problem with the patch, I'm
just trying to understand the mechanism.]

Well, after some more tests I realized, that the problem still shows up ==> forget the patch and sorry for the noise. It seems to be more complicated (sometimes it runs, sometimes I see other crashes, etc.).

Wolfgang.


_______________________________________________
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help

Reply via email to