mmap behaviour colliding with wine
Patrick Georgi
patrick at georgi-clan.de
Sun May 8 16:01:10 PDT 2011
Hi,
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
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/94413 also applies to
DragonFly.
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)?
Patrick
More information about the Kernel
mailing list