I did indeed try commenting that out too which in effect made pageout_scan a noop but that resulted in the system 'freezing' after launching the 3rd process. I could enter the kernel debugger but not interact with the system via any console.I was so surprised by this that I actually commented out all of the code in vm_pageout_scan except for the page balancing but it still did the same.Have you tried commenting the page balancing?
The issue could match the issues I'm still experiencing on buildds where I have just disabled swap.It is the page balancing that is reducing the resident memory total for my first process. Each page that is moved gets marked as VM_PROT_NONE and the task's (pmap) resident_count decremented accordingly. There doesn't seem to be any equivalent increment associated with the page that it is moved to.That's odd indeed, do you have the series of calls that leads to the decrement? (e.g. a backtrace)
It is just the code path through vm_page_seg_balance_page():
*) A page is removed from the inactive or active page queue of a segment to be moved to another.
*) The old page is removed from various mappings and data structures and a new page allocated in the destination segment.
*) The call to vm_page_remove_mappings() sets the page protection to VM_PROT_NONE and decreases the resident page count.
*) The page data is then copied from old to new. There is a call to pmap_clear_modify for the new page if the old page wasn't 'dirty' but what about the case where the old page was dirty? Shouldn't there be something happen to the pmap data for that case as well ?
Your test case is valid, it'll be useful to investigate further.
I'm spending a lot of time trying to unravel the workings of the memory management. It is hard enough a task at all but with only the source code to examine it's very hard to work out what was really meant in the case where it might not be working as designed. I will continue to delve.
Regards,
Mike.