linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Marcelo Tosatti <marcelo@conectiva.com.br>
To: "Stephen C. Tweedie" <sct@redhat.com>
Cc: Linus Torvalds <torvalds@transmeta.com>,
	"David S. Miller" <davem@redhat.com>,
	Rik van Riel <riel@conectiva.com.br>,
	linux-mm@kvack.org
Subject: Re: Subtle MM bug
Date: Mon, 8 Jan 2001 19:52:00 -0200 (BRST)	[thread overview]
Message-ID: <Pine.LNX.4.21.0101081824480.6087-100000@freak.distro.conectiva> (raw)
In-Reply-To: <20010108181028.F9321@redhat.com>

On Mon, 8 Jan 2001, Stephen C. Tweedie wrote:

> > _really_ well on many loads, but this one we do badly on. And from what
> > I've been able to see so far, it's because we're just too damn good at
> > waiting on page_launder() and doing refill_inactive_scan().
> 
> do_try_to_free_pages() is trying to
> 
> 	/*
> 	 * If needed, we move pages from the active list
> 	 * to the inactive list. We also "eat" pages from
> 	 * the inode and dentry cache whenever we do this.
> 	 */
> 	if (free_shortage() || inactive_shortage()) {
> 		shrink_dcache_memory(6, gfp_mask);
> 		shrink_icache_memory(6, gfp_mask);
> 		ret += refill_inactive(gfp_mask, user);
> 	} else {
> 
> So we're refilling the inactive list regardless of its current size
> whenever free_shortage() is true.  In the situation you describe,
> there's no point refilling the inactive list too far beyond the
> ability of the swapper to launder it, regardless of whether
> free_shortage() is set.

Agreed.

After some fights me and Rik agreed on doing a per-zone inactive shortage
check in inactive_shortage().

This allow us to check _only_ for inactive_shortage()  before calling
refill_inactive().

> 
> refill_inactive contains exactly the opposite logic: it breaks out if
> 
> 		/*
> 		 * If we either have enough free memory, or if
> 		 * page_launder() will be able to make enough
> 		 * free memory, then stop.
> 		 */
> 		if (!inactive_shortage() || !free_shortage())
> 			goto done;
> 
> but that still means that we're doing unnecessary inactive list
> refilling whenever free_shortage() is true: this test only occurs
> after we've tried at least one swap_out().  We're calling
> refill_inactive if either condition is true, but we're staying inside
> it only if both conditions are true.
> 
> Shouldn't we really just be making the refill_inactive() here depend
> on inactive_shortage() alone, not free_shortage()?  By refilling the
> inactive list too agressively we actually end up discarding aging
> information which might be of use to us.

Yes.

I've removed the free_shortage() of refill_inactive() in the patch.

Comments are welcome.


--- linux.orig/mm/vmscan.c	Thu Jan  4 02:45:26 2001
+++ linux/mm/vmscan.c	Mon Jan  8 20:43:59 2001
@@ -808,6 +808,9 @@
 int inactive_shortage(void)
 {
 	int shortage = 0;
+	pg_data_t *pgdat = pgdat_list;
+
+	/* Is the inactive dirty list too small? */
 
 	shortage += freepages.high;
 	shortage += inactive_target;
@@ -818,7 +821,27 @@
 	if (shortage > 0)
 		return shortage;
 
-	return 0;
+	/* If not, do we have enough per-zone pages on the inactive list? */
+
+	shortage = 0;
+
+	do {
+		int i;
+		for(i = 0; i < MAX_NR_ZONES; i++) {
+			int zone_shortage;
+			zone_t *zone = pgdat->node_zones+ i;
+
+			zone_shortage = zone->pages_high;
+			zone_shortage -= zone->inactive_dirty_pages;
+			zone_shortage -= zone->inactive_clean_pages;
+			zone_shortage -= zone->free_pages;
+			if (zone_shortage > 0)
+				shortage += zone_shortage;
+		}
+		pgdat = pgdat->node_next;
+	} while (pgdat);
+
+	return shortage;
 }
 
 /*
@@ -861,12 +884,13 @@
 		}
 
 		/*
-		 * don't be too light against the d/i cache since
-	   	 * refill_inactive() almost never fail when there's
-	   	 * really plenty of memory free. 
+		 * Only free memory from i/d caches if we have 
+		 * are under low memory.
 		 */
-		shrink_dcache_memory(priority, gfp_mask);
-		shrink_icache_memory(priority, gfp_mask);
+		if(free_shortage()) {
+			shrink_dcache_memory(priority, gfp_mask);
+			shrink_icache_memory(priority, gfp_mask);
+		}
 
 		/*
 		 * Then, try to page stuff out..
@@ -878,11 +902,10 @@
 		}
 
 		/*
-		 * If we either have enough free memory, or if
-		 * page_launder() will be able to make enough
+		 * If page_launder() will be able to make enough
 		 * free memory, then stop.
 		 */
-		if (!inactive_shortage() || !free_shortage())
+		if (!inactive_shortage())
 			goto done;
 
 		/*
@@ -922,14 +945,20 @@
 
 	/*
 	 * If needed, we move pages from the active list
-	 * to the inactive list. We also "eat" pages from
-	 * the inode and dentry cache whenever we do this.
+	 * to the inactive list.
+	 */
+	if (inactive_shortage())
+		ret += refill_inactive(gfp_mask, user);
+
+	/* 	
+	 * Delete pages from the inode and dentry cache 
+	 * if memory is low. 
 	 */
-	if (free_shortage() || inactive_shortage()) {
+	if (free_shortage()) {
 		shrink_dcache_memory(6, gfp_mask);
 		shrink_icache_memory(6, gfp_mask);
-		ret += refill_inactive(gfp_mask, user);
-	} else {
+	} else { 
+
 		/*
 		 * Reclaim unused slab cache memory.
 		 */



--
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.eu.org/Linux-MM/

  reply	other threads:[~2001-01-08 21:52 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200101080602.WAA02132@pizda.ninka.net>
2001-01-08  6:42 ` Linus Torvalds
2001-01-08 13:11   ` Marcelo Tosatti
2001-01-08 16:42     ` Rik van Riel
2001-01-08 17:43     ` Linus Torvalds
2001-01-08 13:57   ` Stephen C. Tweedie
2001-01-08 17:29     ` Linus Torvalds
2001-01-08 18:10       ` Stephen C. Tweedie
2001-01-08 21:52         ` Marcelo Tosatti [this message]
2001-01-09  0:28           ` Linus Torvalds
2001-01-08 23:49             ` Marcelo Tosatti
2001-01-09  3:12               ` Linus Torvalds
2001-01-09 20:33                 ` Marcelo Tosatti
2001-01-09 22:44                   ` Linus Torvalds
2001-01-09 21:33                     ` Marcelo Tosatti
2001-01-09 22:11                       ` Yet another bogus piece of do_try_to_free_pages() Marcelo Tosatti
2001-01-10  0:06                         ` Linus Torvalds
2001-01-10  6:39                           ` Marcelo Tosatti
2001-01-10 22:19                             ` Roger Larsson
2001-01-11  0:11                             ` Zlatko Calusic
2001-01-17  6:58                               ` Rik van Riel
2001-01-17  6:07                                 ` Marcelo Tosatti
2001-01-17 19:04                                 ` Zlatko Calusic
2001-01-17 19:22                                   ` Ingo Molnar
2001-01-18  0:55                                     ` Rik van Riel
2001-01-17  6:52                           ` Rik van Riel
2001-01-09 23:58                       ` Subtle MM bug Linus Torvalds
2001-01-09 22:21                         ` Marcelo Tosatti
2001-01-10  0:23                           ` Linus Torvalds
2001-01-10  0:12                             ` Marcelo Tosatti
2001-01-10 11:29                               ` Stephen C. Tweedie
2001-01-11  3:30                             ` Marcelo Tosatti
2001-01-11  9:42                               ` Stephen C. Tweedie
2001-01-11 15:24                                 ` Marcelo Tosatti
2001-01-17  4:54                 ` Rik van Riel
2001-01-08 16:45   ` Rik van Riel
2001-01-08 17:50     ` Linus Torvalds
2001-01-08 18:21       ` Rik van Riel
2001-01-08 18:38         ` Linus Torvalds
2001-01-07 20:59 Zlatko Calusic
2001-01-07 21:37 ` Rik van Riel
2001-01-07 22:33   ` Zlatko Calusic
2001-01-09  2:01   ` Zlatko Calusic
2001-01-17  4:48     ` Rik van Riel
2001-01-17 18:53       ` Zlatko Calusic
2001-01-18  1:32         ` Rik van Riel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.21.0101081824480.6087-100000@freak.distro.conectiva \
    --to=marcelo@conectiva.com.br \
    --cc=davem@redhat.com \
    --cc=linux-mm@kvack.org \
    --cc=riel@conectiva.com.br \
    --cc=sct@redhat.com \
    --cc=torvalds@transmeta.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox