On Fri, Dec 21, 2012 at 4:59 PM, Michel Lespinasse <[email protected]> wrote: > On Fri, Dec 21, 2012 at 4:36 PM, Andy Lutomirski <[email protected]> wrote: >> On Thu, Dec 20, 2012 at 4:49 PM, Michel Lespinasse <[email protected]> wrote: >>> 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 from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
