Messages in this thread | | | Date | Thu, 17 Dec 2009 09:43:22 -0500 | From | Rik van Riel <> | Subject | Re: FWD: [PATCH v2] vmscan: limit concurrent reclaimers in shrink_zone |
| |
On 12/17/2009 07:23 AM, Larry Woodman wrote:
>>> The system would not respond so I dont know whats going on yet. I'll >>> add debug code to figure out why its in that state as soon as I get >>> access to the hardware. > > This was in response to Rik's first patch and seems to be fixed by the > latest path set. > > Finally, having said all that, the system still struggles reclaiming > memory with > ~10000 processes trying at the same time, you fix one bottleneck and it > moves > somewhere else. The latest run showed all but one running process > spinning in > page_lock_anon_vma() trying for the anon_vma_lock. I noticed that there are > ~5000 vma's linked to one anon_vma, this seems excessive!!!
I have some ideas on how to keep processes waiting better on the per zone reclaim_wait waitqueue.
For one, we should probably only do the lots-free wakeup if we have more than zone->pages_high free pages in the zone - having each of the waiters free some memory one after another should not be a problem as long as we do not have too much free memory in the zone.
Currently it's a hair trigger, with the threshold for processes going into the page reclaim path and processes exiting it "plenty free" being exactly the same.
Some hysteresis there could help.
-- All rights reversed.
| |