mmap behaviour colliding with wine

Patrick Georgi patrick at
Sun May 8 16:01:10 PDT 2011


I'm looking into getting wine to run on DragonFly. So far my journey
brought me to trace mmap. It seems that the issue detailed in also applies to

In short, mmap considers only the memory after code+data unless
MAP_FIXED/MAP_TRYFIXED is used. As wine relocates its code to ~2GB, and
stuffs memory above it (to prevent the dynamic loader from using it, as
some win32 apps rely on a 2GB/2GB split with the top half used by the
kernel), no memory is considered free, even though there's still ~1GB
free (wine also maps the first GB, though I don't know how much of that
is reclaimed by its own memory management).

Setting the vm.randomize_mmap sysctl to 1 brings wine beyond that point
most of the time (only so it fails somewhere else), and following
src/sys/vm/vm_map.c (vm_map_hint()) that actually tells the kernel to
use a more liberal algorithm, so it seems I'm on the right track.

So, what's the rationale about limiting mmap in that way instead of
considering all free memory (at least as a last resort)?


More information about the Kernel mailing list