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: Tue, 26 May 2015 16:32:26 +0000
- Subject: Re: Support for Intel X1000
- Authentication-results: sourceware.org; auth=none
- References: <1431426490 dot 3246 dot 29 dot camel at intel dot com> <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>
> 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.
PARENT: locking
fork to PARENT
fork to CHILD0 <- mlockall(MCL_CURRENT)
PARENT: 1 : 385 : 0xb7786000 : 0xdce
CHILD0: 0 : 386 : 0xb7786000 : 0xa630
PARENT: release
CHILD0: locking
CHILD0: 1 : 386 : 0xb7786000 : 0xa630
PARENT: 0 : 385 : 0xb7786000 : 0xdce
Ray K
On Tue, 2015-05-26 at 15:16 +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:
>
> Hi Rich,
>
> ok ... I am seeing slightly different behavior.
>
> From the mlockall man page ....
> "MCL_FUTURE Lock all pages which will become mapped into the address
> space of the process in the future. These could be for instance new
> pages required by a growing heap and stack as well as new
> memory-mapped files or shared memory regions".
>
> So I wrote some test code ...
> 1. mlockall(MCL_FUTURE) upfront.
> 2. mmap a page, with MAP_PRIVATE | MAP_ANONYMOUS, PROT_READ |
> PROT_WRITE.
> 3. print out the virt to physical page mapping
> 4. fork()
> 5. print out the virt to physical page mapping (parent and child).
>
> What I see is that same physical page is mapped into both parent and
> child process space until a process writes to it - at which point a CoW
> Page Fault occurs. A new physical page is then mapped into the writing
> process address space.
>
> INIT: <- mlockall(MCL_FUTURE) && mmap 1 page
> PARENT: locking <- parent process writes to CoW Page.
> fork to PARENT <- fork(), page is set as CoW
> fork to CHILD0
> PARENT: 1 : 13560 : 0xf7760000 : 0x399d5 <- PID, Page Virt Addr, Page
> Phy Addr
> CHILD0: 0 : 13561 : 0xf7760000 : 0x399d5
> PARENT: release <- 1st write to 0x399d5 after fork(), causes #PF
> allocating 0x6d548.
> CHILD0: locking
> PARENT: 0 : 13560 : 0xf7760000 : 0x6d548 <- PID, Virt Addr, Phy Addr
> CHILD0: 1 : 13561 : 0xf7760000 : 0x399d5
> ...
>
> Is there any known way to change this behavior and eliminate the CoW?
>
> Ray K
>
>
>
>
>
>
>