We don't want to make all kmem_pagealloc_physmem calls blindly elevate privileges, that can make a lot of harm as well, because it would allow all processes (and notably non-root) eat all memory without caring to leave room for the few paths which really need vm privilege.
OK. I was thinking that almost all memory allocation from user space would result in requests for new memory pages via a page fault which ends up ultimately in vm_page_grab(). They wouldn't have elevated privilege and so would be blocked when memory is low as per normal. Pages requested for kernel operations via kmem_pagealloc_physmem() (which then calls vm_page_grab()) might however be permitted to succeed. Sorry about my misunderstanding; I need to look at that more closely.
I'll look into that.So it's mach-defpager which need to be given vm_privilege. If that's not already so, that is what really needs to be fixed. Normally that's already done by mach-defpager's wire_thread() which uses thread_wire(), but possibly a bug makes it miss some mach-defpager thread, and that's what needs to be fixed.
I'll remove that from my test bed for the moment and possibly implement your description and see if that helps at all.The final suggestion contained in the attached patch is to allow memory allocation within a memory segment that would normally be paused (vm_page_alloc_paused==1) but actually has nr_free_pages high enough to permit the allocation within that segment. In such cases the pausing was triggered by a different memory segment.I don't think we want that: if we let other segments fill up as well, then we won't have room to push data from the filled segment to other segments. I'll however agree if the segment has room beyond seg->high_free_pages to accomodate the data that we want to migrate (essentially the sum of max(seg->high_free_pages - seg->nr_free_pages, 0) for seg among the segments below)
I've seen your update which I'll test locally.- if (double_paging && !object->pager_initialized) { + if (!object->pager_initialized) { vm_object_pager_create(object); }So this would be my recent fd63a4bbf6f2201846f37afba348c5db88364c44 The point of the patch was to cope with the case where there is no DMM. I indeed got the condition from for the internal objects which of course will never have double_paging even if we have a DMM. I have changed the condition, could you try it?
Thanks again for the investigation, this will be really useful to fix building large packages etc.
I hope that I can help with that.
Best regards,
Mike.