Re: [PATCH 1/2] vmscan: shrink_slab() require number of lru_pages, not page order
From: Minchan Kim
Date: Sat Jun 26 2010 - 21:04:00 EST
On Fri, Jun 25, 2010 at 11:07 PM, Christoph Lameter
> On Fri, 25 Jun 2010, KOSAKI Motohiro wrote:
>> Fix simple argument error. Usually 'order' is very small value than
>> lru_pages. then it can makes unnecessary icache dropping.
> This is going to reduce the delta that is added to shrinker->nr
> significantly thereby increasing the number of times that shrink_slab() is
> What does the "lru_pages" parameter do in shrink_slab()? Looks
> like its only role is as a divison factor in a complex calculation of
> pages to be scanned.
Yes. But I think it can make others confuse like this.
Except zone_reclaim, lru_pages had been used for balancing slab
reclaim VS page reclaim.
So lru_page naming is a good.
But in 0ff38490, you observed rather corner case.
AFAIU with your description, you wanted to shrink slabs until
unsuccessful or reached the limit.
So you intentionally passed order instead of the number of lru pages
for shrinking many slabs as possible as.
So at least, we need some comment to prevent confusion.
diff --git a/mm/vmscan.c b/mm/vmscan.c
index 9c7e57c..5523eae 100644
@@ -2626,6 +2626,9 @@ 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.
+ * We pass order instead of lru_pages for shrinking slab
+ * as much as possible.
while (shrink_slab(sc.nr_scanned, gfp_mask, order) &&
zone_page_state(zone, NR_SLAB_RECLAIMABLE) >
> do_try_to_free_pages passes 0 as "lru_pages" to shrink_slab() when trying
> to do cgroup lru scans. Why is that?
memcg doesn't call shrink_slab.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/