Messages in this thread | | | Date | Fri, 16 Jul 2010 10:44:24 +0900 | Subject | Re: [PATCH v2 2/2] vmscan: shrink_slab() require number of lru_pages, not page order | From | Minchan Kim <> |
| |
On Fri, Jul 16, 2010 at 10:39 AM, KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> wrote: >> > nr_slab_pages0 = zone_page_state(zone, NR_SLAB_RECLAIMABLE); >> > if (nr_slab_pages0 > zone->min_slab_pages) { >> > + unsigned long lru_pages = zone_reclaimable_pages(zone); >> > + >> > /* >> > * shrink_slab() does not currently allow us to determine how >> > * many pages were freed in this zone. So we take the current >> > @@ -2622,7 +2624,7 @@ static int __zone_reclaim(struct zone *zone, gfp_t gfp_mask, unsigned int order) >> > * Note that shrink_slab will free memory on all zones and may >> > * take a long time. >> > */ >> > - while (shrink_slab(sc.nr_scanned, gfp_mask, order) && >> > + while (shrink_slab(sc.nr_scanned, gfp_mask, lru_pages) && >> > (zone_page_state(zone, NR_SLAB_RECLAIMABLE) + nr_pages > >> > nr_slab_pages0)) >> > ; >> >> Wouldn't it be better to recalculate zone_reclaimable_pages() each time >> around the loop? For example, shrink_icache_memory()->prune_icache() >> will remove pagecache from an inode if it hits the tail of the list. >> This can change the number of reclaimable pages by squigabytes, but >> this code thinks nothing changed? > > Ah, I missed this. incrementa patch is here. > > thank you! > > > > From 8f7c70cfb4a25f8292a59564db6c3ff425a69b53 Mon Sep 17 00:00:00 2001 > From: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> > Date: Fri, 16 Jul 2010 08:40:01 +0900 > Subject: [PATCH] vmscan: recalculate lru_pages on each shrink_slab() > > Andrew Morton pointed out shrink_slab() may change number of reclaimable > pages (e.g. shrink_icache_memory()->prune_icache() will remove unmapped > pagecache). > > So, we need to recalculate lru_pages on each shrink_slab() calling. > This patch fixes it. > > Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Reviewed-by: Minchan Kim <minchan.kim@gmail.com>
It does make sense.
-- Kind regards, Minchan Kim -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |