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 15:16:34 +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>
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