Thread (40 messages) 40 messages, 8 authors, 2013-03-12

Re: [PATCH 0/9] Avoid populating unbounded num of ptes with mmap_sem held

From: Andy Lutomirski <luto@amacapital.net>
Date: 2012-12-22 01:09:58
Also in: lkml

On Fri, Dec 21, 2012 at 4:59 PM, Michel Lespinasse [off-list ref] wrote:
On Fri, Dec 21, 2012 at 4:36 PM, Andy Lutomirski [off-list ref] wrote:
quoted
On Thu, Dec 20, 2012 at 4:49 PM, Michel Lespinasse [off-list ref] wrote:
quoted
We have many vma manipulation functions that are fast in the typical case,
but can optionally be instructed to populate an unbounded number of ptes
within the region they work on:
- mmap with MAP_POPULATE or MAP_LOCKED flags;
- remap_file_pages() with MAP_NONBLOCK not set or when working on a
  VM_LOCKED vma;
- mmap_region() and all its wrappers when mlock(MCL_FUTURE) is in effect;
- brk() when mlock(MCL_FUTURE) is in effect.
Something's buggy here.  My evil test case is stuck with lots of
threads spinning at 100% system time.  Stack traces look like:

[<0000000000000000>] __mlock_vma_pages_range+0x66/0x70
[<0000000000000000>] __mm_populate+0xf9/0x150
[<0000000000000000>] vm_mmap_pgoff+0x9f/0xc0
[<0000000000000000>] sys_mmap_pgoff+0x7e/0x150
[<0000000000000000>] sys_mmap+0x22/0x30
[<0000000000000000>] system_call_fastpath+0x16/0x1b
[<0000000000000000>] 0xffffffffffffffff

perf top says:

 38.45%  [kernel]            [k] __mlock_vma_pages_range
 33.04%  [kernel]            [k] __get_user_pages
 28.18%  [kernel]            [k] __mm_populate

The tasks in question use MCL_FUTURE but not MAP_POPULATE.  These
tasks are immune to SIGKILL.
Looking into it.

There seems to be a problem with mlockall - the following program
fails in an unkillable way even before my changes:

#include <sys/mman.h>
#include <stdio.h>
#include <stdint.h>

int main(void) {
  void *p = mmap(NULL, 0x100000000000,
                 PROT_READ | PROT_WRITE,
                 MAP_PRIVATE | MAP_ANON | MAP_NORESERVE,
                 -1, 0);
  printf("p: %p\n", p);
  mlockall(MCL_CURRENT);
  return 0;
}

I think my changes propagate this existing problem so it now shows up
in more places :/
Hmm.  I'm using MCL_FUTURE with MAP_NORESERVE, but those mappings are
not insanely large.  Should MAP_NORESERVE would negate MCL_FUTURE?
I'm doing MAP_NORESERVE, PROT_NONE to prevent pages from being
allocated in the future -- I have no intention of ever using them.

The other odd thing I do is use MAP_FIXED to replace MAP_NORESERVE pages.

--Andy

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help