linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] vmscan: recalculate lru_pages on each priority
@ 2010-06-25  9:13 KOSAKI Motohiro
  2010-06-25 14:15 ` Rik van Riel
                   ` (2 more replies)
  0 siblings, 3 replies; 5+ messages in thread
From: KOSAKI Motohiro @ 2010-06-25  9:13 UTC (permalink / raw)
  To: LKML, linux-mm, Andrew Morton, Rik van Riel, Johannes Weiner,
	Minchan Kim
  Cc: kosaki.motohiro

shrink_zones() need relatively long time. and lru_pages can be
changed dramatically while shrink_zones().
then, lru_pages need recalculate on each priority.

Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
---
 mm/vmscan.c |   21 ++++++++-------------
 1 files changed, 8 insertions(+), 13 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 0c961f1..0ebfe12 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -1785,7 +1785,6 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist,
 	bool all_unreclaimable;
 	unsigned long total_scanned = 0;
 	struct reclaim_state *reclaim_state = current->reclaim_state;
-	unsigned long lru_pages = 0;
 	struct zoneref *z;
 	struct zone *zone;
 	enum zone_type high_zoneidx = gfp_zone(sc->gfp_mask);
@@ -1796,18 +1795,6 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist,
 
 	if (scanning_global_lru(sc))
 		count_vm_event(ALLOCSTALL);
-	/*
-	 * mem_cgroup will not do shrink_slab.
-	 */
-	if (scanning_global_lru(sc)) {
-		for_each_zone_zonelist(zone, z, zonelist, high_zoneidx) {
-
-			if (!cpuset_zone_allowed_hardwall(zone, GFP_KERNEL))
-				continue;
-
-			lru_pages += zone_reclaimable_pages(zone);
-		}
-	}
 
 	for (priority = DEF_PRIORITY; priority >= 0; priority--) {
 		sc->nr_scanned = 0;
@@ -1819,6 +1806,14 @@ static unsigned long do_try_to_free_pages(struct zonelist *zonelist,
 		 * over limit cgroups
 		 */
 		if (scanning_global_lru(sc)) {
+			unsigned long lru_pages = 0;
+			for_each_zone_zonelist(zone, z, zonelist, high_zoneidx) {
+				if (!cpuset_zone_allowed_hardwall(zone, GFP_KERNEL))
+					continue;
+
+				lru_pages += zone_reclaimable_pages(zone);
+			}
+
 			shrink_slab(sc->nr_scanned, sc->gfp_mask, lru_pages);
 			if (reclaim_state) {
 				sc->nr_reclaimed += reclaim_state->reclaimed_slab;
-- 
1.6.5.2



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] vmscan: recalculate lru_pages on each priority
  2010-06-25  9:13 [PATCH] vmscan: recalculate lru_pages on each priority KOSAKI Motohiro
@ 2010-06-25 14:15 ` Rik van Riel
  2010-06-26 23:33 ` Minchan Kim
  2010-06-27 11:34 ` Johannes Weiner
  2 siblings, 0 replies; 5+ messages in thread
From: Rik van Riel @ 2010-06-25 14:15 UTC (permalink / raw)
  To: KOSAKI Motohiro
  Cc: LKML, linux-mm, Andrew Morton, Johannes Weiner, Minchan Kim

On 06/25/2010 05:13 AM, KOSAKI Motohiro wrote:
> shrink_zones() need relatively long time. and lru_pages can be
> changed dramatically while shrink_zones().
> then, lru_pages need recalculate on each priority.
>
> Signed-off-by: KOSAKI Motohiro<kosaki.motohiro@jp.fujitsu.com>

Acked-by: Rik van Riel <riel@redhat.com>

-- 
All rights reversed

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] vmscan: recalculate lru_pages on each priority
  2010-06-25  9:13 [PATCH] vmscan: recalculate lru_pages on each priority KOSAKI Motohiro
  2010-06-25 14:15 ` Rik van Riel
@ 2010-06-26 23:33 ` Minchan Kim
  2010-06-27 11:34 ` Johannes Weiner
  2 siblings, 0 replies; 5+ messages in thread
From: Minchan Kim @ 2010-06-26 23:33 UTC (permalink / raw)
  To: KOSAKI Motohiro
  Cc: LKML, linux-mm, Andrew Morton, Rik van Riel, Johannes Weiner

On Fri, Jun 25, 2010 at 6:13 PM, KOSAKI Motohiro
<kosaki.motohiro@jp.fujitsu.com> wrote:
> shrink_zones() need relatively long time. and lru_pages can be
> changed dramatically while shrink_zones().
> then, lru_pages need recalculate on each priority.
>
> Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Reviewed-by: Minchan Kim <minchan.kim@gmail.com>

Kosaki's patch seems to be reasonable to me.

I looked into background reclaim. It already has done until now.
(ie, background : dynamic lru_pages in each priority, direct reclaim :
static lru_pages in each priority).
Firstly In 53dce00d, Andrew did it.
Why does he do it with unbalance?
I guess it was just a mistake.

-- 
Kind regards,
Minchan Kim

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] vmscan: recalculate lru_pages on each priority
  2010-06-25  9:13 [PATCH] vmscan: recalculate lru_pages on each priority KOSAKI Motohiro
  2010-06-25 14:15 ` Rik van Riel
  2010-06-26 23:33 ` Minchan Kim
@ 2010-06-27 11:34 ` Johannes Weiner
  2010-06-28  1:39   ` KOSAKI Motohiro
  2 siblings, 1 reply; 5+ messages in thread
From: Johannes Weiner @ 2010-06-27 11:34 UTC (permalink / raw)
  To: KOSAKI Motohiro; +Cc: LKML, linux-mm, Andrew Morton, Rik van Riel, Minchan Kim

On Fri, Jun 25, 2010 at 06:13:20PM +0900, KOSAKI Motohiro wrote:
> shrink_zones() need relatively long time. and lru_pages can be
> changed dramatically while shrink_zones().
> then, lru_pages need recalculate on each priority.

In the direct reclaim path, we bail out of that loop after
SWAP_CLUSTER_MAX reclaimed pages, so in this case, decreasing priority
levels actually mean we do _not_ make any progress and the total
number of lru pages should not change (much).  The possible distortion
in shrink_slab() is small.

However, for the suspend-to-disk case the reclaim target can be a lot
higher and we inevitably end up at higher priorities even though we
make progress, but fail to increase pressure on the shrinkers as well
without your patch.

Acked-by: Johannes Weiner <hannes@cmpxchg.org>

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [PATCH] vmscan: recalculate lru_pages on each priority
  2010-06-27 11:34 ` Johannes Weiner
@ 2010-06-28  1:39   ` KOSAKI Motohiro
  0 siblings, 0 replies; 5+ messages in thread
From: KOSAKI Motohiro @ 2010-06-28  1:39 UTC (permalink / raw)
  To: Johannes Weiner
  Cc: kosaki.motohiro, LKML, linux-mm, Andrew Morton, Rik van Riel,
	Minchan Kim

> On Fri, Jun 25, 2010 at 06:13:20PM +0900, KOSAKI Motohiro wrote:
> > shrink_zones() need relatively long time. and lru_pages can be
> > changed dramatically while shrink_zones().
> > then, lru_pages need recalculate on each priority.
> 
> In the direct reclaim path, we bail out of that loop after
> SWAP_CLUSTER_MAX reclaimed pages, so in this case, decreasing priority
> levels actually mean we do _not_ make any progress and the total
> number of lru pages should not change (much).  The possible distortion
> in shrink_slab() is small.

Oh, you seems forgot the case when much thread enter try_to_free_pages()
concurrently.

> 
> However, for the suspend-to-disk case the reclaim target can be a lot
> higher and we inevitably end up at higher priorities even though we
> make progress, but fail to increase pressure on the shrinkers as well
> without your patch.
> 
> Acked-by: Johannes Weiner <hannes@cmpxchg.org>



--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2010-06-28  1:39 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-06-25  9:13 [PATCH] vmscan: recalculate lru_pages on each priority KOSAKI Motohiro
2010-06-25 14:15 ` Rik van Riel
2010-06-26 23:33 ` Minchan Kim
2010-06-27 11:34 ` Johannes Weiner
2010-06-28  1:39   ` KOSAKI Motohiro

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox