Support for Intel X1000

[Kinsella, Ray]

ignore this - fault was being generated by the runtime linker on the
getchar.

Ray K

On Wed, 2015-05-20 at 19:14 +0000, Kinsella, Ray wrote:
> On Wed, 2015-05-20 at 10:15 -0400, dalias@libc.org wrote:
> > On Wed, May 20, 2015 at 01:54:13PM +0000, Kinsella, Ray wrote:
> >
> > If this is true, it's a bug in the implementation of mlockall. The
> > whole point of memory locking is to prevent the need to allocate
> > memory at page fault time, which matters for multiple reasons,
> > including at least:
> > 
> > 1. Real-time applications that can't accept the possible latency.
> > 2. Reasons related to commit charge/overcommit/OOM-killer.
> 
> CoW pages may be a little different - as they are already resident for
> for read, with the page marked read-only. The fault is generated then on
> write, what is happening on the fault is a copy of the page is made and
> original page is then marked rw.
> 
> I wrote a trivial test with a single variable in the data segment,
> measure the process page_faults, write to the variable and measure the
> page_faults again. 
> 
> static int volatile indicator = 0;
> 
> int main(int count, char *argv) {
> 
>     mlockall(MCL_CURRENT);
> 
>     getchar();
> 
>     indicator = 1;
> 
>     getchar();
> }
> 
> [rkinsell~]$ ps -o min_flt,maj_flt `pidof test`
>  MINFL  MAJFL
>     70      0
> [rkinsell~]$ ps -o min_flt,maj_flt `pidof test`
>  MINFL  MAJFL
>     71      0
> 
> > > It clobbers the process the process state in an unrecoverable way. The
> > > problem doesn't affect the Kernel, as the Kernel doesn't page fault.  
> > 
> > In that case I think mlockall (with the above bug fixed) is a viable
> > kernel-side workaround.
> 
> Think you have the right idea here - best approach may be to identify
> the bug in the Kernel - set_cpu_bug(c, X86_BUG_LOCK);
> 
> and then automatically pre-populate the pages when CoW pages are
> requested (i.e. trigger the fault up-front). 
> 
> Ray K