Cool, you found this doesn't hurt performance too much? Can't you remove the check from the reclaim code now? (The check here should give a more timely wait anyway) This is good because it should eliminate most all cases of extra waiting. I wonder if you've also thought of doing the check in the allocation path too as we were discussing? (this would give a better FIFO behaviour under memory pressure but I could easily agree it is not worth the cost) On Mon, Mar 08, 2010 at 11:48:22AM +0000, Mel Gorman wrote: > When a batch of pages have been freed to the buddy allocator, it is possible > that it is enough to push a zone above its watermarks. This patch puts a > check in the free path for zone pressure. It's in a common path but for > the most part, it should only be checking if a linked list is empty and > have minimal performance impact. > > Signed-off-by: Mel Gorman <mel@xxxxxxxxx> > --- > mm/page_alloc.c | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/mm/page_alloc.c b/mm/page_alloc.c > index 1383ff9..3c8e8b7 100644 > --- a/mm/page_alloc.c > +++ b/mm/page_alloc.c > @@ -562,6 +562,9 @@ static void free_pcppages_bulk(struct zone *zone, int count, > } while (--count && --batch_free && !list_empty(list)); > } > spin_unlock(&zone->lock); > + > + /* A batch of pages have been freed so check zone pressure */ > + check_zone_pressure(zone); > } > > static void free_one_page(struct zone *zone, struct page *page, int order, > -- > 1.6.5 -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxxx For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>