Messages in this thread | | | Date | Wed, 25 Jan 2012 12:17:45 -0500 | From | Rik van Riel <> | Subject | Re: [PATCH v2 -mm 1/3] mm: reclaim at order 0 when compaction is enabled |
| |
On 01/25/2012 11:07 AM, Mel Gorman wrote: > On Wed, Jan 25, 2012 at 10:27:28AM -0500, Rik van Riel wrote:
>> Maybe this is the place to check (in balanced_pgdat) ? >> >> /* >> * We do this so kswapd doesn't build up large >> priorities for >> * example when it is freeing in parallel with >> allocators. It >> * matches the direct reclaim path behaviour in >> terms of impact >> * on zone->*_priority. >> */ >> if (sc.nr_reclaimed>= SWAP_CLUSTER_MAX) >> break; >> > > It would be a good place all right. Preferably it would tie into > compaction_ready() to decide whether to continue reclaiming or not.
Good point. We can just track compaction_ready for all of the zones and bail out if at least one of the zones is ready for compaction (somehow taking the classzone index into account?).
Or maybe simply keep reclaiming order 0 pages until all the memory zones in the pgdat are ready for compaction?
>>>> @@ -2922,8 +2939,6 @@ out: >>>> >>>> /* If balanced, clear the congested flag */ >>>> zone_clear_flag(zone, ZONE_CONGESTED); >>>> - if (i<= *classzone_idx) >>>> - balanced += zone->present_pages; >>>> } >>> >>> Why is this being deleted? It is still used by pgdat_balanced(). >> >> This is outside of the big while loop and is not used again >> in the function. > > How about here? > > if (all_zones_ok || (order&& pgdat_balanced(pgdat, balanced, *classzone_idx))) > break; /* kswapd: all done */ > > Either way, it looks like something that should be in its own patch.
That code is above the lines that I removed.
The only way to get back there is to jump up to loop_again, from where we will get to the main loop, where balanced is zeroed out.
If you want I will split this out into its own patch.
| |