To date, mlockall(MCL_FUTURE) has had the unfortunate side effect of

blocking vm map entry and object coalescing for the calling process.
However, there is no reason that mlockall(MCL_FUTURE) should block
such coalescing.  This change enables it.

Reviewed by:	kib, markj
Tested by:	pho
MFC after:	6 weeks
Differential Revision:	https://reviews.freebsd.org/D16413
This commit is contained in:
Alan Cox 2018-07-28 04:06:33 +00:00
parent 4faa0dc193
commit 737e25f7eb

View File

@ -1277,10 +1277,9 @@ vm_map_insert(vm_map_t map, vm_object_t object, vm_ooffset_t offset,
vm_object_clear_flag(object, OBJ_ONEMAPPING);
VM_OBJECT_WUNLOCK(object);
} else if (prev_entry != &map->header &&
prev_entry->eflags == protoeflags &&
(prev_entry->eflags & ~MAP_ENTRY_USER_WIRED) == protoeflags &&
(cow & (MAP_STACK_GROWS_DOWN | MAP_STACK_GROWS_UP)) == 0 &&
prev_entry->end == start && prev_entry->wired_count == 0 &&
(prev_entry->cred == cred ||
prev_entry->end == start && (prev_entry->cred == cred ||
(prev_entry->object.vm_object != NULL &&
prev_entry->object.vm_object->cred == cred)) &&
vm_object_coalesce(prev_entry->object.vm_object,
@ -1295,7 +1294,11 @@ vm_map_insert(vm_map_t map, vm_object_t object, vm_ooffset_t offset,
*/
if (prev_entry->inheritance == inheritance &&
prev_entry->protection == prot &&
prev_entry->max_protection == max) {
prev_entry->max_protection == max &&
prev_entry->wired_count == 0) {
KASSERT((prev_entry->eflags & MAP_ENTRY_USER_WIRED) ==
0, ("prev_entry %p has incoherent wiring",
prev_entry));
if ((prev_entry->eflags & MAP_ENTRY_GUARD) == 0)
map->size += end - prev_entry->end;
prev_entry->end = end;