mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Felipe Alfaro Solana <felipe_alfaro@linuxmail.org>
To: Mark Gross <mgross@linux.jf.intel.com>
Cc: Pavel Machek <pavel@ucw.cz>, linux-kernel@vger.kernel.org
Subject: Re: swsusp "not enough swap space" 2.6.5-mm6.
Date: Wed, 09 Jun 2004 21:48:00 +0200	[thread overview]
Message-ID: <1086810480.1982.1.camel@teapot.felipe-alfaro.com> (raw)
In-Reply-To: <200406090927.51206.mgross@linux.intel.com>

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

On Wed, 2004-06-09 at 09:27 -0700, Mark Gross wrote:
> On Wednesday 09 June 2004 08:32, Mark Gross wrote:
> > On Tuesday 08 June 2004 16:04, Pavel Machek wrote:
> > > Hi!
> > >
> > > > I'm sorry for not having more information, but the failing computer is
> > > > my home laptop (I'll get more details after work or I'll bring it in
> > > > tomorrow for more details).
> > > >
> > > > Anyway, this thing does software suspend using the 2.6.2-mm1 kernel,
> > > > and last night I was updating it to 2.6.5-mm6, and I started getting
> > > > these not enough disk space errors.
> > > >
> > > > I found your bug fix patch,
> > > > http://marc.theaimsgroup.com/?l=linux-kernel&m=107806008626357&w=2
> > > >  and checked that it is included in the 2.6.5-mm6 kernel I'm using.
> > > >
> > > > Without more information does this problem ring any bells?
> > > >
> > > > Can you recommend a "good" kernel version that does reliable swsusp?
> > >
> > > Get 2.6.6, and set swappiness to 100.
> > >
> > > 								Pavel
> >
> > 2.6.6 still fails, just like the failure reported by the thread independent
> > of swappiness:
> >
> > http://marc.theaimsgroup.com/?t=107806010900002&r=1&w=2
> >
> > However; as hinted in the thread turning off premption does seem to fix the
> > problem.
> >
> 
> Spoke too soon.  My build tree that had the success was 2.6.6-mm6, so I 
> re-built a clean 2.6.6 from tarball using the .config from the successful 
> run, CONFIG_PREEMPT=n.  It fails.  2.6.6-mm5 works, but only if 
> CONFIG_PREEMPT=n.
> 
> I have to get to my day job now, but whats up with the flakieness of the 
> swsusp?  Shouldn't it be mostly working by now?

It's working flawlessly for me with 2.6.7-rc3-mm1. I also applied the
following patches (who knows)...

[-- Attachment #2: swsusp-leak.fix --]
[-- Type: text/plain, Size: 4023 bytes --]

>From linux-kernel-owner@vger.kernel.org Wed Jun  9 16:00:10 2004
Return-Path:
	<linux-kernel-owner+felipe_alfaro=40linuxmail.org-s263939abufinft@vger.kernel.org>
Received: from kerberos.felipe-alfaro.com ([unix socket]) by
	kerberos.felipe-alfaro.com (Cyrus v2.2.3) with LMTP; Wed, 09 Jun 2004
	16:00:10 +0200
X-Sieve: CMU Sieve 2.2
Received: from localhost (localhost.localdomain [127.0.0.1]) by
	kerberos.felipe-alfaro.com (Postfix) with ESMTP id 3306C42E3D for
	<yo@felipe-alfaro.com>; Wed,  9 Jun 2004 16:00:10 +0200 (CEST)
Delivered-To: felipe_alfaro:linuxmail.org@linuxmail.org
Received: from pop24.pr.outblaze.com [205.158.62.125] by localhost with
	POP3 (fetchmail-6.1.0) for yo@felipe-alfaro.com (single-drop); Wed, 09 Jun
	2004 16:00:10 +0200 (CEST)
Received: (qmail 14692 invoked by uid 0); 9 Jun 2004 13:07:17 -0000
X-OB-Received: from unknown (205.158.62.147) by mta45-1.us4.outblaze.com; 9
	Jun 2004 13:07:17 -0000
Received: from vger.kernel.org (vger.kernel.org [12.107.209.244]) by
	spf5-2.us4.outblaze.com (Postfix) with ESMTP id BBEDB19A93B for
	<felipe_alfaro@linuxmail.org>; Wed,  9 Jun 2004 13:07:16 +0000 (GMT)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id
	S263939AbUFINFT (ORCPT <rfc822;felipe_alfaro@linuxmail.org>); Wed, 9 Jun
	2004 09:05:19 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264357AbUFINFT
	(ORCPT <rfc822;linux-kernel-outgoing>); Wed, 9 Jun 2004 09:05:19 -0400
Received: from gprs214-178.eurotel.cz ([160.218.214.178]:62337 "EHLO
	amd.ucw.cz") by vger.kernel.org with ESMTP id S263939AbUFINFG (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>); Wed, 9 Jun 2004 09:05:06 -0400
Received: by amd.ucw.cz (Postfix, from userid 8) id 7DD432BDBB; Wed,  9 Jun
	2004 15:04:51 +0200 (CEST)
Date:	Wed, 9 Jun 2004 15:04:51 +0200
From: Pavel Machek <pavel@ucw.cz>
To: Patrick Mochel <mochel@digitalimplant.org>, kernel list <linux-kernel@vger.kernel.org>, Andrew Morton <akpm@zip.com.au>
Subject: Fix memory leak in swsusp
Message-ID: <20040609130451.GA23107@elf.ucw.cz>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
X-Warning: Reading this can be dangerous to your mental health.
User-Agent: Mutt/1.5.5.1+cvs20040105i
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List:	linux-kernel@vger.kernel.org
X-Evolution-Source: imap://falfaro;auth=GSSAPI@192.168.0.1/
Content-Transfer-Encoding: 8bit

Hi!

This fixes 2 memory leaks in swsusp: during relocating pagedir, eaten
pages were not properly freed in error path and even regular freeing
path was freeing one page too little. Please apply,

								Pavel

--- linux-cvs/kernel/power/swsusp.c	2004-05-22 19:39:01.000000000 +0200
+++ linux/kernel/power/swsusp.c	2004-06-06 00:30:09.000000000 +0200
@@ -503,6 +503,9 @@
 		if (!pbe)
 			continue;
 		pbe->orig_address = (long) page_address(page);
+		/* Copy page is dangerous: it likes to mess with
+		   preempt count on specific cpus. Wrong preempt count is then copied,
+		   oops. */
 		copy_page((void *)pbe->address, (void *)pbe->orig_address);
 		pbe++;
 	}
@@ -923,8 +952,9 @@
 	suspend_pagedir_t *new_pagedir, *old_pagedir = pagedir_nosave;
 	void **eaten_memory = NULL;
 	void **c = eaten_memory, *m, *f;
+	int ret = 0;
 
-	printk("Relocating pagedir");
+	printk("Relocating pagedir ");
 
 	if(!does_collide_order(old_pagedir, (unsigned long)old_pagedir, pagedir_order)) {
 		printk("not necessary\n");
@@ -941,22 +971,23 @@
 		c = eaten_memory;
 	}
 
-	if (!m)
-		return -ENOMEM;
-
-	pagedir_nosave = new_pagedir = m;
-	copy_pagedir(new_pagedir, old_pagedir);
+	if (!m) {
+		printk("out of memory\n");
+		ret = -ENOMEM;
+	} else {
+		pagedir_nosave = new_pagedir = m;
+		copy_pagedir(new_pagedir, old_pagedir);
+	}
 
 	c = eaten_memory;
-	while(c) {
+	while (c) {
 		printk(":");
-		f = *c;
+		f = c;
 		c = *c;
-		if (f)
-			free_pages((unsigned long)f, pagedir_order);
+		free_pages((unsigned long)f, pagedir_order);
 	}
 	printk("|\n");
-	return 0;
+	return ret;
 }
 
 /*


[-- Attachment #3: swsusp-swappiness.patch --]
[-- Type: text/x-patch, Size: 4509 bytes --]

>From linux-kernel-owner@vger.kernel.org Sun May 30 22:00:15 2004
Return-Path:
	<linux-kernel-owner+felipe_alfaro=40linuxmail.org-s264331abue3tse@vger.kernel.org>
Received: from kerberos.felipe-alfaro.com ([unix socket]) by
	kerberos.felipe-alfaro.com (Cyrus v2.2.3) with LMTP; Sun, 30 May 2004
	22:00:15 +0200
X-Sieve: CMU Sieve 2.2
Received: from localhost (localhost.localdomain [127.0.0.1]) by
	kerberos.felipe-alfaro.com (Postfix) with ESMTP id 3BE1B42E7B for
	<yo@felipe-alfaro.com>; Sun, 30 May 2004 22:00:15 +0200 (CEST)
Delivered-To: felipe_alfaro:linuxmail.org@linuxmail.org
Received: from pop24.pr.outblaze.com [205.158.62.125] by localhost with
	POP3 (fetchmail-6.1.0) for yo@felipe-alfaro.com (single-drop); Sun, 30 May
	2004 22:00:15 +0200 (CEST)
Received: (qmail 30523 invoked by uid 0); 30 May 2004 19:50:03 -0000
X-OB-Received: from unknown (205.158.62.147) by mta45-1.us4.outblaze.com;
	30 May 2004 19:50:03 -0000
Received: from vger.kernel.org (vger.kernel.org [12.107.209.244]) by
	spf5-2.us4.outblaze.com (Postfix) with ESMTP id 2EFE019AA00 for
	<felipe_alfaro@linuxmail.org>; Sun, 30 May 2004 19:50:01 +0000 (GMT)
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id
	S264331AbUE3TsE (ORCPT <rfc822;felipe_alfaro@linuxmail.org>); Sun, 30 May
	2004 15:48:04 -0400
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S264335AbUE3TsE
	(ORCPT <rfc822;linux-kernel-outgoing>); Sun, 30 May 2004 15:48:04 -0400
Received: from gprs214-89.eurotel.cz ([160.218.214.89]:55680 "EHLO
	amd.ucw.cz") by vger.kernel.org with ESMTP id S264331AbUE3Tr7 (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>); Sun, 30 May 2004 15:47:59 -0400
Received: by amd.ucw.cz (Postfix, from userid 8) id F361E2BA5C; Sun, 30 May
	2004 21:47:31 +0200 (CEST)
Date:	Sun, 30 May 2004 21:47:31 +0200
From: Pavel Machek <pavel@suse.cz>
To: Nick Piggin <nickpiggin@yahoo.com.au>
Cc: Nigel Cunningham <ncunningham@linuxmail.org>, Andrew Morton <akpm@zip.com.au>, Stuart Young <cef-lkml@optusnet.com.au>, linux-kernel@vger.kernel.org, Rob Landley <rob@landley.net>, seife@suse.de
Subject: Re: swappiness=0 makes software suspend fail.
Message-ID: <20040530194731.GA895@elf.ucw.cz>
References: <200405280000.56742.rob@landley.net>
	 <20040528215642.GA927@elf.ucw.cz>
	 <200405291905.20925.cef-lkml@optusnet.com.au>
	 <40B85024.2040505@linuxmail.org> <20040529223648.GB1535@elf.ucw.cz>
	 <40B94546.4040605@yahoo.com.au>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <40B94546.4040605@yahoo.com.au>
X-Warning: Reading this can be dangerous to your mental health.
User-Agent: Mutt/1.5.4i
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List:	linux-kernel@vger.kernel.org
X-Evolution-Source: imap://falfaro;auth=GSSAPI@192.168.0.1/
Content-Transfer-Encoding: 8bit

Hi!

> >Andrew, in 2.6.6 shrink_all_memory() does not work if swappiness ==
> >0. shrink_all_memory() calls balance_pgdat(), that calls
> >shrink_zone(), and that calls refill_inactive_zone(), which looks at
> >swappiness.
> >
> >Additional parameter to all these calls neutralizing swappiness would
> >help, as would temporarily setting swappiness to 100 in
> >shrink_all_memory. Is there a less ugly solution?
> 
> I have a cleanup patch that allows this sort of thing to easily
> be passed into the lower levels of reclaim functions. I don't
> know if it would be to Andrew's taste though...
> 
> It basically replaces all function parameters in vmscan.c with
> 
> struct scan_control {
> 	unsigned long nr_to_scan;
> 	unsigned long nr_scanned;
> 	unsigned long nr_reclaimed;
> 	unsigned int gfp_mask;
> 	struct page_state ps;
> 	int may_writepage;
> };
> 
> So you could easily add a field for swsusp.
> 
> Until something like this goes through, please don't fuglify
> vmscan.c any more than it is... do the saving and restoring
> thing that Nigel suggested please.

Okay, this should solve it.
							Pavel

--- clean/mm/vmscan.c	2004-05-20 23:08:37.000000000 +0200
+++ linux/mm/vmscan.c	2004-05-30 21:45:41.000000000 +0200
@@ -1098,10 +1098,13 @@
 	pg_data_t *pgdat;
 	int nr_to_free = nr_pages;
 	int ret = 0;
+	int old_swappiness = vm_swappiness;
 	struct reclaim_state reclaim_state = {
 		.reclaimed_slab = 0,
 	};
 
+	vm_swappiness = 100;
+
 	current->reclaim_state = &reclaim_state;
 	for_each_pgdat(pgdat) {
 		int freed;
@@ -1115,6 +1118,8 @@
 			break;
 	}
 	current->reclaim_state = NULL;
+
+	vm_swappiness = old_swappiness;
 	return ret;
 }
 #endif

  reply	other threads:[~2004-06-09 19:48 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-06-08 15:29 Mark Gross
2004-06-08 23:04 ` Pavel Machek
2004-06-09 15:32   ` Mark Gross
2004-06-09 16:27     ` Mark Gross
2004-06-09 19:48       ` Felipe Alfaro Solana [this message]
2004-06-09 21:28         ` Mark Gross
2004-06-09 21:13       ` Pavel Machek
2004-06-09 21:00     ` Pavel Machek

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=1086810480.1982.1.camel@teapot.felipe-alfaro.com \
    --to=felipe_alfaro@linuxmail.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mgross@linux.jf.intel.com \
    --cc=pavel@ucw.cz \
    /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

all inboxes | Powered by JetHome®