All of lore.kernel.org
 help / color / mirror / Atom feed
* Skip reclaim_mapped determination if we do not swap
@ 2006-02-11 21:39 Christoph Lameter
  2006-02-11 21:50 ` Andrew Morton
  0 siblings, 1 reply; 7+ messages in thread
From: Christoph Lameter @ 2006-02-11 21:39 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-mm, nickpiggin, marcelo.tosatti

This puts the variables and the way to get to reclaim_mapped in one 
block. And allows zone_reclaim or other things to skip the determination 
(maybe this whole block of code does not belong into 
refill_inactive_zone()?)

Signed-off-by: Christoph Lameter <clameter@sgi.com>

Index: linux-2.6.16-rc2/mm/vmscan.c
===================================================================
--- linux-2.6.16-rc2.orig/mm/vmscan.c	2006-02-11 13:29:51.000000000 -0800
+++ linux-2.6.16-rc2/mm/vmscan.c	2006-02-11 13:31:15.000000000 -0800
@@ -1180,9 +1180,43 @@ refill_inactive_zone(struct zone *zone, 
 	struct page *page;
 	struct pagevec pvec;
 	int reclaim_mapped = 0;
-	long mapped_ratio;
-	long distress;
-	long swap_tendency;
+
+	if (sc->may_swap) {
+		long mapped_ratio;
+		long distress;
+		long swap_tendency;
+
+		/*
+		 * `distress' is a measure of how much trouble we're having reclaiming
+		 * pages.  0 -> no problems.  100 -> great trouble.
+		 */
+		distress = 100 >> zone->prev_priority;
+
+		/*
+		 * The point of this algorithm is to decide when to start reclaiming
+		 * mapped memory instead of just pagecache.  Work out how much memory
+		 * is mapped.
+		 */
+		mapped_ratio = (sc->nr_mapped * 100) / total_memory;
+
+		/*
+		 * Now decide how much we really want to unmap some pages.  The mapped
+		 * ratio is downgraded - just because there's a lot of mapped memory
+		 * doesn't necessarily mean that page reclaim isn't succeeding.
+		 *
+		 * The distress ratio is important - we don't want to start going oom.
+		 *
+		 * A 100% value of vm_swappiness overrides this algorithm altogether.
+		 */
+		swap_tendency = mapped_ratio / 2 + distress + vm_swappiness;
+
+		/*
+		 * Now use this metric to decide whether to start moving mapped memory
+		 * onto the inactive list.
+		 */
+		if (swap_tendency >= 100)
+			reclaim_mapped = 1;
+	}
 
 	lru_add_drain();
 	spin_lock_irq(&zone->lru_lock);
@@ -1192,37 +1226,6 @@ refill_inactive_zone(struct zone *zone, 
 	zone->nr_active -= pgmoved;
 	spin_unlock_irq(&zone->lru_lock);
 
-	/*
-	 * `distress' is a measure of how much trouble we're having reclaiming
-	 * pages.  0 -> no problems.  100 -> great trouble.
-	 */
-	distress = 100 >> zone->prev_priority;
-
-	/*
-	 * The point of this algorithm is to decide when to start reclaiming
-	 * mapped memory instead of just pagecache.  Work out how much memory
-	 * is mapped.
-	 */
-	mapped_ratio = (sc->nr_mapped * 100) / total_memory;
-
-	/*
-	 * Now decide how much we really want to unmap some pages.  The mapped
-	 * ratio is downgraded - just because there's a lot of mapped memory
-	 * doesn't necessarily mean that page reclaim isn't succeeding.
-	 *
-	 * The distress ratio is important - we don't want to start going oom.
-	 *
-	 * A 100% value of vm_swappiness overrides this algorithm altogether.
-	 */
-	swap_tendency = mapped_ratio / 2 + distress + vm_swappiness;
-
-	/*
-	 * Now use this metric to decide whether to start moving mapped memory
-	 * onto the inactive list.
-	 */
-	if (swap_tendency >= 100 && sc->may_swap)
-		reclaim_mapped = 1;
-
 	while (!list_empty(&l_hold)) {
 		cond_resched();
 		page = lru_to_page(&l_hold);

--
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] 7+ messages in thread

* Re: Skip reclaim_mapped determination if we do not swap
  2006-02-11 21:39 Skip reclaim_mapped determination if we do not swap Christoph Lameter
@ 2006-02-11 21:50 ` Andrew Morton
  2006-02-11 22:10   ` Christoph Lameter
  2006-02-11 22:25   ` Christoph Lameter
  0 siblings, 2 replies; 7+ messages in thread
From: Andrew Morton @ 2006-02-11 21:50 UTC (permalink / raw)
  To: Christoph Lameter; +Cc: linux-mm, nickpiggin, marcelo.tosatti

Christoph Lameter <clameter@engr.sgi.com> wrote:
>
> This puts the variables and the way to get to reclaim_mapped in one 
> block. And allows zone_reclaim or other things to skip the determination 
> (maybe this whole block of code does not belong into 
> refill_inactive_zone()?)

For your enjoyment, here is a picture of what the resulting code looks like
in an 80-col window:

	http://www.zip.com.au/~akpm/linux/patches/stuff/x.jpeg

It would make things somewhat easier if I didn't have to go fixing up after
you all the time.

--
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] 7+ messages in thread

* Re: Skip reclaim_mapped determination if we do not swap
  2006-02-11 21:50 ` Andrew Morton
@ 2006-02-11 22:10   ` Christoph Lameter
  2006-02-11 23:29     ` Andrew Morton
  2006-02-11 22:25   ` Christoph Lameter
  1 sibling, 1 reply; 7+ messages in thread
From: Christoph Lameter @ 2006-02-11 22:10 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-mm, nickpiggin, marcelo.tosatti

On Sat, 11 Feb 2006, Andrew Morton wrote:

> For your enjoyment, here is a picture of what the resulting code looks like
> in an 80-col window:
> 
> 	http://www.zip.com.au/~akpm/linux/patches/stuff/x.jpeg

Ahh. Yes looks really ragged...
 
> It would make things somewhat easier if I didn't have to go fixing up after
> you all the time.

I can fix this if this is the final resting place of the code. But should 
this piece of code really be there? Doesnt it belong ito shrink_zone() or 
even in try_to_free_pages() or balance_pgdat(). Shouldn't we pass 
reclaim_mapped as a parameter to refill_inactive_zone?

--
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] 7+ messages in thread

* Re: Skip reclaim_mapped determination if we do not swap
  2006-02-11 21:50 ` Andrew Morton
  2006-02-11 22:10   ` Christoph Lameter
@ 2006-02-11 22:25   ` Christoph Lameter
  2006-02-16 15:01     ` pluggable reclaim infrastructure Marcelo Tosatti
  1 sibling, 1 reply; 7+ messages in thread
From: Christoph Lameter @ 2006-02-11 22:25 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-mm, nickpiggin, marcelo.tosatti

Here is a new rev of the earlier patch that moves the determination of
reclaim_mapped into shrink_zone(). This means that refill_inactive does 
not depend on scan control anymore. And its properly formatted for 80 
columns

Signed-off-by: Christoph Lameter <clameter@sgi.com>

Index: linux-2.6.16-rc2/mm/vmscan.c
===================================================================
--- linux-2.6.16-rc2.orig/mm/vmscan.c	2006-02-11 13:35:20.000000000 -0800
+++ linux-2.6.16-rc2/mm/vmscan.c	2006-02-11 14:22:07.000000000 -0800
@@ -1168,21 +1168,16 @@ done:
  * But we had to alter page->flags anyway.
  */
 static void
-refill_inactive_zone(struct zone *zone, struct scan_control *sc)
+refill_inactive_zone(struct zone *zone, unsigned long nr_pages, int reclaim_mapped)
 {
 	int pgmoved;
 	int pgdeactivate = 0;
 	int pgscanned;
-	int nr_pages = sc->nr_to_scan;
 	LIST_HEAD(l_hold);	/* The pages which were snipped off */
 	LIST_HEAD(l_inactive);	/* Pages to go onto the inactive_list */
 	LIST_HEAD(l_active);	/* Pages to go onto the active_list */
 	struct page *page;
 	struct pagevec pvec;
-	int reclaim_mapped = 0;
-	long mapped_ratio;
-	long distress;
-	long swap_tendency;
 
 	lru_add_drain();
 	spin_lock_irq(&zone->lru_lock);
@@ -1192,37 +1187,6 @@ refill_inactive_zone(struct zone *zone, 
 	zone->nr_active -= pgmoved;
 	spin_unlock_irq(&zone->lru_lock);
 
-	/*
-	 * `distress' is a measure of how much trouble we're having reclaiming
-	 * pages.  0 -> no problems.  100 -> great trouble.
-	 */
-	distress = 100 >> zone->prev_priority;
-
-	/*
-	 * The point of this algorithm is to decide when to start reclaiming
-	 * mapped memory instead of just pagecache.  Work out how much memory
-	 * is mapped.
-	 */
-	mapped_ratio = (sc->nr_mapped * 100) / total_memory;
-
-	/*
-	 * Now decide how much we really want to unmap some pages.  The mapped
-	 * ratio is downgraded - just because there's a lot of mapped memory
-	 * doesn't necessarily mean that page reclaim isn't succeeding.
-	 *
-	 * The distress ratio is important - we don't want to start going oom.
-	 *
-	 * A 100% value of vm_swappiness overrides this algorithm altogether.
-	 */
-	swap_tendency = mapped_ratio / 2 + distress + vm_swappiness;
-
-	/*
-	 * Now use this metric to decide whether to start moving mapped memory
-	 * onto the inactive list.
-	 */
-	if (swap_tendency >= 100 && sc->may_swap)
-		reclaim_mapped = 1;
-
 	while (!list_empty(&l_hold)) {
 		cond_resched();
 		page = lru_to_page(&l_hold);
@@ -1304,6 +1268,7 @@ shrink_zone(struct zone *zone, struct sc
 {
 	unsigned long nr_active;
 	unsigned long nr_inactive;
+	int reclaim_mapped = 0;
 
 	atomic_inc(&zone->reclaim_in_progress);
 
@@ -1325,12 +1290,52 @@ shrink_zone(struct zone *zone, struct sc
 	else
 		nr_inactive = 0;
 
+	if (sc->may_swap) {
+		long mapped_ratio;
+		long distress;
+		long swap_tendency;
+
+		/*
+		 * `distress' is a measure of how much trouble we're having
+		 * reclaiming  pages.  0 -> no problems.  100 -> great trouble.
+		 */
+		distress = 100 >> zone->prev_priority;
+
+		/*
+		 * The point of this algorithm is to decide when to start
+		 * reclaiming mapped memory instead of just pagecache.
+		 * Work out how much memory is mapped.
+		 */
+		mapped_ratio = (sc->nr_mapped * 100) / total_memory;
+
+		/*
+		 * Now decide how much we really want to unmap some pages.
+		 * The mappe ratio is downgraded - just because there's a lot
+		 * of mapped memory doesn't necessarily mean that page reclaim
+		 * isn't succeeding.
+		 *
+		 * The distress ratio is important - we don't want to start
+		 * going oom.
+		 *
+		 * A 100% value of vm_swappiness overrides this algorithm
+		 * altogether.
+		 */
+		swap_tendency = mapped_ratio / 2 + distress + vm_swappiness;
+
+		/*
+		 * Now use this metric to decide whether to start moving
+		 * mapped memory onto the inactive list.
+		 */
+		if (swap_tendency >= 100)
+			reclaim_mapped = 1;
+	}
+
 	while (nr_active || nr_inactive) {
 		if (nr_active) {
 			sc->nr_to_scan = min(nr_active,
 					(unsigned long)sc->swap_cluster_max);
 			nr_active -= sc->nr_to_scan;
-			refill_inactive_zone(zone, sc);
+			refill_inactive_zone(zone, sc->nr_to_scan, reclaim_mapped);
 		}
 
 		if (nr_inactive) {

--
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] 7+ messages in thread

* Re: Skip reclaim_mapped determination if we do not swap
  2006-02-11 22:10   ` Christoph Lameter
@ 2006-02-11 23:29     ` Andrew Morton
  2006-02-12  0:59       ` Christoph Lameter
  0 siblings, 1 reply; 7+ messages in thread
From: Andrew Morton @ 2006-02-11 23:29 UTC (permalink / raw)
  To: Christoph Lameter; +Cc: linux-mm, nickpiggin, marcelo.tosatti

Christoph Lameter <clameter@engr.sgi.com> wrote:
>
> But should 
>  this piece of code really be there? Doesnt it belong ito shrink_zone() or 
>  even in try_to_free_pages() or balance_pgdat(). Shouldn't we pass 
>  reclaim_mapped as a parameter to refill_inactive_zone?

Well, it's only used in refill_inactive_zone().  Does it matter much where
it is?

--
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] 7+ messages in thread

* Re: Skip reclaim_mapped determination if we do not swap
  2006-02-11 23:29     ` Andrew Morton
@ 2006-02-12  0:59       ` Christoph Lameter
  0 siblings, 0 replies; 7+ messages in thread
From: Christoph Lameter @ 2006-02-12  0:59 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-mm, nickpiggin, marcelo.tosatti

On Sat, 11 Feb 2006, Andrew Morton wrote:

> Christoph Lameter <clameter@engr.sgi.com> wrote:
> >
> > But should 
> >  this piece of code really be there? Doesnt it belong ito shrink_zone() or 
> >  even in try_to_free_pages() or balance_pgdat(). Shouldn't we pass 
> >  reclaim_mapped as a parameter to refill_inactive_zone?
> 
> Well, it's only used in refill_inactive_zone().  Does it matter much where
> it is?

If it is repeatedly evaluated when reclaiming then it matters. It also 
makes refill_inactive_zone() simpler if the statistical considerations are 
in one place in shrink_zone().

--
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] 7+ messages in thread

* pluggable reclaim infrastructure
  2006-02-11 22:25   ` Christoph Lameter
@ 2006-02-16 15:01     ` Marcelo Tosatti
  0 siblings, 0 replies; 7+ messages in thread
From: Marcelo Tosatti @ 2006-02-16 15:01 UTC (permalink / raw)
  To: Christoph Lameter, Peter Zijlstra
  Cc: Andrew Morton, linux-mm, nickpiggin, Bob Picco

Hi,

On Sat, Feb 11, 2006 at 02:25:57PM -0800, Christoph Lameter wrote:
> Here is a new rev of the earlier patch that moves the determination of
> reclaim_mapped into shrink_zone(). This means that refill_inactive does 
> not depend on scan control anymore. And its properly formatted for 80 
> columns

Can we please hold off this reclaim tweaks for a while? Peter's
pluggable page-replace infrastructure does more fundamental and
important changes to the reclaim code (along with better organization
and separation of the heuristics such as reclaim_mapped, etc.), and
having vmscan.c to change often (as it is now) is just a pain in the
arse to handle.

Its not going to take long for the patchset to be sent for
review/shaping.

--
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] 7+ messages in thread

end of thread, other threads:[~2006-02-16 15:01 UTC | newest]

Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-02-11 21:39 Skip reclaim_mapped determination if we do not swap Christoph Lameter
2006-02-11 21:50 ` Andrew Morton
2006-02-11 22:10   ` Christoph Lameter
2006-02-11 23:29     ` Andrew Morton
2006-02-12  0:59       ` Christoph Lameter
2006-02-11 22:25   ` Christoph Lameter
2006-02-16 15:01     ` pluggable reclaim infrastructure Marcelo Tosatti

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.