All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jeff Garzik <jgarzik@pobox.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org, ak@suse.de, axboe@suse.de
Subject: Re: Hang on x86-64, 2.6.9-rc3-bk4
Date: Sat, 16 Oct 2004 19:43:59 -0400	[thread overview]
Message-ID: <4171B23F.6060305@pobox.com> (raw)
In-Reply-To: <20041016154818.271a394b.akpm@osdl.org>

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]

Andrew Morton wrote:
> Jeff Garzik <jgarzik@pobox.com> wrote:
> 
>>The only really notable changes in -bk3 -> -bk4 are the signal changes, 
>>something in mm/vmscan.c.
>>
> 
> 
> I'd be suspecting the vmscan.c change, but we allegedly fixed that later on.
> Can you try reverting it?  (Can't reproduce the problem here)


Verified -- reverting the vmscan.c changeset (attached) fixed my hang.

This hang is definitely present from -rc3-bk4 through -final, so a fix 
is not presented in mainline.

	Jeff



[-- Attachment #2: patch --]
[-- Type: text/plain, Size: 2874 bytes --]

# ChangeSet
#   2004/10/03 09:16:48-07:00 nickpiggin@yahoo.com.au 
#   [PATCH] vm: prevent kswapd pageout priority windup
#   
#   Now that we are correctly kicking off kswapd early (before the synch
#   reclaim watermark), it is really doing asynchronous pageout.  This has
#   exposed a latent problem where allocators running at the same time will
#   make kswapd think it is getting into trouble, and cause too much swapping
#   and suboptimal behaviour.
#   
#   This patch changes the kswapd scanning algorithm to use the same metrics
#   for measuring pageout success as the synchronous reclaim path - namely, how
#   much work is required to free SWAP_CLUSTER_MAX pages.
#   
#   This should make things less fragile all round, and has the added benefit
#   that kswapd will continue running so long as memory is low and it is
#   managing to free pages, rather than going through the full priority loop,
#   then giving up.  Should result in much better behaviour all round,
#   especially when there are concurrent allocators.
#   
#   akpm: the patch was confirmed to fix up the excessive swapout which Ray Bryant
#   <raybry@sgi.com> has been reporting.
#   
#   Signed-off-by: Nick Piggin <nickpiggin@yahoo.com.au>
#   Signed-off-by: Andrew Morton <akpm@osdl.org>
#   Signed-off-by: Linus Torvalds <torvalds@osdl.org>
# 
diff -Nru a/mm/vmscan.c b/mm/vmscan.c
--- a/mm/vmscan.c	2004-10-16 19:42:30 -04:00
+++ b/mm/vmscan.c	2004-10-16 19:42:30 -04:00
@@ -968,12 +968,16 @@
 static int balance_pgdat(pg_data_t *pgdat, int nr_pages)
 {
 	int to_free = nr_pages;
+	int all_zones_ok;
 	int priority;
 	int i;
-	int total_scanned = 0, total_reclaimed = 0;
+	int total_scanned, total_reclaimed;
 	struct reclaim_state *reclaim_state = current->reclaim_state;
 	struct scan_control sc;
 
+loop_again:
+	total_scanned = 0;
+	total_reclaimed = 0;
 	sc.gfp_mask = GFP_KERNEL;
 	sc.may_writepage = 0;
 	sc.nr_mapped = read_page_state(nr_mapped);
@@ -987,10 +991,11 @@
 	}
 
 	for (priority = DEF_PRIORITY; priority >= 0; priority--) {
-		int all_zones_ok = 1;
 		int end_zone = 0;	/* Inclusive.  0 = ZONE_DMA */
 		unsigned long lru_pages = 0;
 
+		all_zones_ok = 1;
+
 		if (nr_pages == 0) {
 			/*
 			 * Scan in the highmem->dma direction for the highest
@@ -1072,6 +1077,15 @@
 		 */
 		if (total_scanned && priority < DEF_PRIORITY - 2)
 			blk_congestion_wait(WRITE, HZ/10);
+
+		/*
+		 * We do this so kswapd doesn't build up large priorities for
+		 * example when it is freeing in parallel with allocators. It
+		 * matches the direct reclaim path behaviour in terms of impact
+		 * on zone->*_priority.
+		 */
+		if (total_reclaimed >= SWAP_CLUSTER_MAX)
+			break;
 	}
 out:
 	for (i = 0; i < pgdat->nr_zones; i++) {
@@ -1079,6 +1093,9 @@
 
 		zone->prev_priority = zone->temp_priority;
 	}
+	if (!all_zones_ok)
+		goto loop_again;
+
 	return total_reclaimed;
 }
 

  reply	other threads:[~2004-10-16 23:44 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-16 21:40 Hang on x86-64, 2.6.9-rc3-bk4 Jeff Garzik
2004-10-16 21:46 ` Jeff Garzik
2004-10-16 22:48   ` Andrew Morton
2004-10-16 23:43     ` Jeff Garzik [this message]
2004-10-17  0:14       ` Andrew Morton
2004-10-17  0:25         ` Jeff Garzik
2004-10-17  0:28           ` Andrew Morton
2004-10-17  0:51         ` Jeff Garzik
2004-10-17  1:21           ` Andrew Morton
2004-10-17  3:39             ` Jeff Garzik
2004-10-17  5:46               ` Nick Piggin
2004-10-17 13:30                 ` Jeff Garzik
2004-10-17 13:49                   ` Nick Piggin
2004-10-17 14:00                     ` Jeff Garzik
2004-10-17 14:19                       ` Nick Piggin
2004-10-17 13:31             ` Jeff Garzik
2004-10-17  1:24           ` Nick Piggin
2004-10-17  2:16             ` Jeff Garzik
2004-10-17  2:19               ` Nick Piggin
2004-10-17  2:31                 ` Nick Piggin
2004-10-17  3:10                   ` Jeff Garzik
2004-10-17  3:20                     ` Nick Piggin
2004-10-17  3:05                 ` Jeff Garzik
2004-10-17  3:07                   ` Nick Piggin
2004-10-17  3:13                     ` Jeff Garzik
2004-10-18 18:45               ` Jeff Garzik

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=4171B23F.6060305@pobox.com \
    --to=jgarzik@pobox.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=axboe@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    /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 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.