This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Support for Intel X1000
- From: "Kinsella, Ray" <ray dot kinsella at intel dot com>
- To: "dalias at libc dot org" <dalias at libc dot org>
- Cc: "carlos at redhat dot com" <carlos at redhat dot com>, "fweimer at redhat dot com" <fweimer at redhat dot com>, "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>
- Date: Mon, 8 Jun 2015 17:20:32 +0000
- Subject: Re: Support for Intel X1000
- Authentication-results: sourceware.org; auth=none
- References: <5552104C dot 1020806 at redhat dot com> <20150512152207 dot GW17573 at brightrain dot aerifal dot cx> <1431513937 dot 2622 dot 24 dot camel at intel dot com> <20150513170809 dot GY17573 at brightrain dot aerifal dot cx> <555397D0 dot 70808 at redhat dot com> <20150515012433 dot GC17573 at brightrain dot aerifal dot cx> <1432130053 dot 17726 dot 6 dot camel at intel dot com> <20150520141538 dot GV17573 at brightrain dot aerifal dot cx> <1432653394 dot 4631 dot 25 dot camel at intel dot com> <1432657945 dot 4631 dot 33 dot camel at intel dot com> <20150526184834 dot GF17573 at brightrain dot aerifal dot cx>
Hi Rich,
I completed the prototype using ld_preload and it works well at the
expense of over-provisioning memory. To catch all cases, it turns out
you need to enforce mlockall both at pre-init and fork, as large
data-segments are also faulted into memory.
I also tried implementing a more conservative scheme using maps to
figure out the data segments/heap/stack etc so that not everything had
to be mlock'ed but found the benefit to be marginal.
The simplest kernel level fix is going to be call mlockall(MCL_FUTURE)
at process initialization and at fork ...
Ray K
On Tue, 2015-05-26 at 14:48 -0400, dalias@libc.org wrote:
> On Tue, May 26, 2015 at 04:32:26PM +0000, Kinsella, Ray wrote:
> > > Is there any known way to change this behavior and eliminate the CoW?
> >
> > Apologies - to answer my own question ...
> >
> > "Memory locks are not inherited by a child created via fork(2) and are
> > automatically removed (unlocked) during an execve(2) or when the process
> > terminates. The mlockall() MCL_FUTURE setting is not inherited by a
> > child created via fork(2) and is cleared during an execve(2)."
> >
> > mlockall(MCL_CURRENT) after the fork, triggers the CoW upfront.
>
> Excellent. In a kernel-based workaround, the kernel would enforce
> adding the mlockall at fork time, and then running arbitrary binaries
> would be safe.
>
> Rich