A correction to my previous post on this problem: the memory in question was
previously allocated heap, that was apparently not yet paged in. The pointer
to the memory was in bss, so, at the time, I assumed the page fault memory
was in bss as well. I have a "solution" which is working for now, to write
(zero out) dynamically allocated memory before first use. (The dynamic
allocation is after the mlockall() ).
My application is a legacy C++ program, which has an initialization phase:
where all RT tasks are created and all memory is allocated; and a run phase:
where the task T_WARNSW mode is enabled, to report unwanted modes switches.
I am in the process of porting this application from Linux-2.4.27+rtai-3.1.0
to Linux-2.6.17.14+Xenomai-2.2.4. (As a side note, it has now become
interesting to consider how and if page faults were affectinging the
Linux-2.4+RTAI version of this application.)
From the discussions in this thread, there will always be a non-zero
probability that my application will still encounter future page faults. So
I've decided to enable T_WARNSW for the applicaion while under development,
but T_WARNSW will not be enabled for deployed applications. Instead, I may
periodically parse /proc/xenomai/faults, and /proc/xenomai/stat .
Jeff
On Thursday 25 January 2007 04:50, Philippe Gerum wrote:
> Gilles is working on a patch that solves a number of on-demand mapping
> issues initially observed on ARM and ppc, but generic enough to affect
> other archs; I'll merge it into the I-pipe 1.7 series for x86 in a near
> future.
_______________________________________________
Xenomai-help mailing list
[email protected]
https://mail.gna.org/listinfo/xenomai-help
