From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4DA6E5FB.1050204@domain.hid> Date: Thu, 14 Apr 2011 14:18:03 +0200 From: Gilles Chanteperdrix MIME-Version: 1.0 References: In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai-help] avoiding page faults List-Id: Help regarding installation and common use of Xenomai List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jeff Weber Cc: xenomai@xenomai.org Jeff Weber wrote: > I wish to avoid unwanted transitions of POSIX pthreads to secondary mode due > to page faults. > > Does calling > mlockall(MCL_CURRENT | MCL_FUTURE) > > lock pages when the memory is allocated, or referenced? > > From reviewing Xenomai, Linux RT_PREEMPT, and RTAI code, it appears the > answer is that memory is locked when the page is "referenced" (not > allocated), and that referencing by write is preferred over referencing by > read. xeno_fault_stack() appears to pre-fault a subset of the stack when > turning the calling thread into a Xenomai thread. > > If true, then I should allocate my own stack for each pthread created in my > program, and write every page ahead of time, then > call pthread_attr_setstack() prior to thread creation. I should also write > every page of every dynamically allocated memory object. > > Please help me verify if this understanding is correct. mlockall(MCL_CURRENT) locks all the memory currently mapped. mlockall(MCL_FUTURE) will lock all the memory when it is allocated/mapped. The only thing which remains allocated on demand is the main thread stack. This explains why we use xeno_fault_stack(), which faults a "reasonable" amount of stack, in order to get the kernel to allocate and map memory. -- Gilles.