From: Pavel Machek <pavel@suse.cz>
To: Grzegorz Piotr Jaskiewicz <gj@pointblue.com.pl>
Cc: kernel list <linux-kernel@vger.kernel.org>
Subject: Re: swsusp: fix error handling in "not enough swap space"
Date: Mon, 26 Apr 2004 22:54:49 +0200 [thread overview]
Message-ID: <20040426205449.GD24587@elf.ucw.cz> (raw)
In-Reply-To: <408D7555.1000607@pointblue.com.pl>
Hi!
> >>>Quite easy to say. I don't really understeand all changes that 've been
> >>>done over mm between 2.6.6-rc2-bk2 and 2.6.5.
> >>>
> >>>
> >
> >I know its easy to say ;-).
> >
> >
> I am looking forward to see someone explaining me what has changed there
> acctually. This time, I am sure, obviously, kernel is counting free
> pages wrong. At least it does it incorrectly when it's about to
> 'hibernate'.
I do not know what went wrong there. If I did, I'd just fix it.
*But* if your test program doing malloc() in loop broke, you probably
want to post test program to l-k, get akpm's attetion, and make
someone fix it.
> >If you do something stupid, its okay that kernel is not able to
> >suspend. F3 on /dev/kmem counts as "something stupid". If you find out
> >something normal user (not root) can do... we are more likely to fix
> >that.
> >
> >I'd say that /dev/kmem issue is not worth fixing. NFS issue may be
> >worth fixing, but I do not use NFS that much. Any other problems?
> >
> >
> Those were just ways of reproducing problem. I know they are not very
> likely to be the case in real life, but simmilar lock up may occur
> somewhere else.
Similar lock probably is there in few more places. Approach is "fix
them one by one". Not the nicest one, but...
So yes, I'm aware there are probably more cases like that; I just
don't know effective way to find them all.
> Well, maybe all beside nfs case. It just happends sometimes that network
> is over congested, just the real life.
freeze_processes tries for 5 seconds. That should be enough to handle
common network congestion.
Pavel
--
934a471f20d6580d5aad759bf0d97ddc
next prev parent reply other threads:[~2004-04-26 20:55 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-04-24 3:17 swsusp: fix error handling in "not enough swap space" Grzegorz Piotr Jaskiewicz
2004-04-24 3:27 ` Nigel Cunningham
2004-04-24 4:04 ` Grzegorz Piotr Jaskiewicz
2004-04-24 4:13 ` Nigel Cunningham
2004-04-24 4:45 ` Grzegorz Piotr Jaskiewicz
2004-04-24 18:35 ` Pavel Machek
2004-04-25 6:48 ` Grzegorz Piotr Jaskiewicz
2004-04-25 20:46 ` Pavel Machek
2004-04-25 8:51 ` Grzegorz Piotr Jaskiewicz
2004-04-25 20:45 ` Pavel Machek
2004-04-26 20:22 ` Grzegorz Piotr Jaskiewicz
2004-04-26 20:32 ` Pavel Machek
[not found] ` <408D7555.1000607@pointblue.com.pl>
2004-04-26 20:54 ` Pavel Machek [this message]
2004-04-24 18:32 ` Pavel Machek
2004-04-25 2:53 ` Grzegorz Piotr Jaskiewicz
-- strict thread matches above, loose matches on Subject: below --
2004-02-29 13:04 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=20040426205449.GD24587@elf.ucw.cz \
--to=pavel@suse.cz \
--cc=gj@pointblue.com.pl \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox