> >
> > 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.]
>
Presumed that touch means "use it" (=memset) I tried to allocate a block
and immediatelly use it (use memset before new heap is created).
But this causes a segmentation fault too.
Inspired by Gilles I set /proc/sys/vm/overcommit_memory to 2, which
worsens
the task behaviour (it crashes every time, not just some times).
Do you have any further suggestions ?
overcommit_memory:
This value contains a flag that enables memory overcommitment.
When this flag is 0, the kernel attempts to estimate the amount
of free memory left when userspace requests more memory.
When this flag is 1, the kernel pretends there is always enough
memory until it actually runs out.
When this flag is 2, the kernel uses a "never overcommit"
policy that attempts to prevent any overcommit of memory.
This feature can be very useful because there are a lot of
programs that malloc() huge amounts of memory "just-in-case"
and don't use much of it.
The default value is 0.
See Documentation/vm/overcommit-accounting and
security/commoncap.c::cap_vm_enough_memory() for more
information.
_______________________________________________
Xenomai-help mailing list
Xenomai-help@gna.org
https://mail.gna.org/listinfo/xenomai-help
