All of lore.kernel.org
 help / color / mirror / Atom feed
From: Roger Larsson <roger.larsson@norran.net>
To: Rik van Riel <riel@conectiva.com.br>
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: Re: [patch *] VM deadlock fix
Date: Thu, 21 Sep 2000 22:28:52 +0200	[thread overview]
Message-ID: <39CA6F84.813057D6@norran.net> (raw)
In-Reply-To: Pine.LNX.4.21.0009211340110.18809-100000@duckman.distro.conectiva

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

Hi,

Tried your patch on 2.2.4-test9-pre4
with the included debug patch applied.

Rebooted, started mmap002

After a while it starts outputting (magic did not work
this time - usually does):

- - -
"VM: try_to_free_pages (result: 1) try_again # 12345"
"VM: try_to_free_pages (result: 1) try_again # 12346"
- - -

My interpretation:
1) try_to_free_pages succeeds (or returns ok when it did not work)
2) __alloc_pages still can't alloc

Maybe it is different limits,
  try_to_free_pages requires less to succeed than
  __alloc_pages_limit requires.
or a bug in
  __alloc_pages_limit(zonelist, order, PAGES_MIN, direct_reclaim)

Note:
  12345  is an example, it loops to over 30000...

/RogerL

Rik van Riel wrote:
> 
> Hi,
> 
> I've found and fixed the deadlocks in the new VM. They turned out
> to be single-cpu only bugs, which explains why they didn't crash my
> SMP tesnt box ;)
> 
> They have to do with the fact that processes schedule away while
> holding IO locks after waking up kswapd. At that point kswapd
> spends its time spinning on the IO locks and single-cpu systems
> will die...
> 
> Due to bad connectivity I'm not attaching this patch but have only
> put it online on my home page:
> 
> http://www.surriel.com/patches/2.4.0-t9p2-vmpatch
> 
> (yes, I'm at a conference now ... the worst beating this patch
> has had is a full night in 'make bzImage' with mem=8m)
> 
> regards,
> 
> Rik
> --
> "What you're running that piece of shit Gnome?!?!"
>        -- Miguel de Icaza, UKUUG 2000
> 
> http://www.conectiva.com/               http://www.surriel.com/
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> Please read the FAQ at http://www.tux.org/lkml/

--
Home page:
  http://www.norran.net/nra02596/

[-- Attachment #2: vmdebug.patch --]
[-- Type: text/plain, Size: 1167 bytes --]

--- mm/page_alloc.c.orig	Thu Sep 21 20:02:54 2000
+++ mm/page_alloc.c	Thu Sep 21 20:49:35 2000
@@ -295,6 +295,7 @@
 	int direct_reclaim = 0;
 	unsigned int gfp_mask = zonelist->gfp_mask;
 	struct page * page = NULL;
+	int try_again_loops = 0;
 
 	/*
 	 * Allocations put pressure on the VM subsystem.
@@ -320,8 +321,10 @@
 	/*
 	 * Are we low on inactive pages?
 	 */
-	if (inactive_shortage() > inactive_target / 2 && free_shortage())
+	if (inactive_shortage() > inactive_target / 2 && free_shortage()) {
+	  printk("VM: inactive shortage wake kswapd\n");
 		wakeup_kswapd(0);
+	}
 
 try_again:
 	/*
@@ -410,6 +413,7 @@
 		 * piece of free memory.
 		 */
 		if (order > 0 && (gfp_mask & __GFP_WAIT)) {
+		  printk("VM: higher order");
 			zone = zonelist->zones;
 			/* First, clean some dirty pages. */
 			page_launder(gfp_mask, 1);
@@ -444,7 +448,9 @@
 		 * processes, etc).
 		 */
 		if (gfp_mask & __GFP_WAIT) {
-			try_to_free_pages(gfp_mask);
+			int success = try_to_free_pages(gfp_mask);
+         printk("VM: try_to_free_pages (result: %d) try_again # %d\n",
+                success, ++try_again_loops);   
 			memory_pressure++;
 			goto try_again;
 		}

  reply	other threads:[~2000-09-21 20:28 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-09-21 16:44 [patch *] VM deadlock fix Rik van Riel
2000-09-21 20:28 ` Roger Larsson [this message]
2000-09-21 23:31   ` Problem remains - page_launder? (Was: Re: [patch *] VM deadlock fix) Roger Larsson
2000-09-21 22:23 ` [patch *] VM deadlock fix David S. Miller
2000-09-22  0:18   ` Andrea Arcangeli
2000-09-21 23:57     ` David S. Miller
2000-09-22  8:39   ` Rik van Riel
2000-09-22  8:54     ` test9-pre5+t9p2-vmpatch VM deadlock during write-intensive workload Molnar Ingo
2000-09-22  9:00       ` Molnar Ingo
2000-09-22  9:08       ` Rik van Riel
2000-09-22  9:14         ` Molnar Ingo
2000-09-22  9:34           ` Molnar Ingo
2000-09-22 10:27             ` Rik van Riel
2000-09-22 13:10               ` André Dahlqvist
2000-09-22 14:10                 ` André Dahlqvist
2000-09-22 16:38                   ` test9-pre3+t9p2-vmpatch VM deadlock during socket I/O Yuri Pudgorodsky
2000-09-22 16:20                 ` test9-pre5+t9p2-vmpatch VM deadlock during write-intensive workload Mohammad A. Haque
2000-09-22 17:39       ` Linus Torvalds
2000-09-25 13:47         ` Rik van Riel
2000-09-22 12:16 ` [patch *] VM deadlock fix Martin Diehl

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=39CA6F84.813057D6@norran.net \
    --to=roger.larsson@norran.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=riel@conectiva.com.br \
    /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.