[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Pageout not succeeding



On 29/05/2025 14:49, Samuel Thibault wrote:
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.

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 look into that.
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'll remove that from my test bed for the moment and possibly implement your description and see if that helps at all.
-    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?
I've seen your update which I'll test locally.
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.


Reply to: