From: Pavel Machek <pavel@ucw.cz>
To: Nigel Cunningham <ncunningham@users.sourceforge.net>
Cc: Andrew Morton <akpm@osdl.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Patrick Mochel <mochel@digitalimplant.org>
Subject: Re: Remove pmdisk from kernel
Date: Tue, 16 Mar 2004 11:17:15 +0100 [thread overview]
Message-ID: <20040316101715.GA2175@elf.ucw.cz> (raw)
In-Reply-To: <1079393256.2043.5.camel@calvin.wpcb.org.au>
On Út 16-03-04 12:27:36, Nigel Cunningham wrote:
> On Tue, 2004-03-16 at 13:56, Pavel Machek wrote:
> >
> > > Most of those changes are hooks to make the freezer for more reliable.
> > > That part of the functionality could be isolated from the bulk of
> > > suspend2. Would that make you happy?
> >
> > Yes, that would be very good. It would make it easy to see actual
> > changes..
> >
> > [I still do not understand why those hooks are neccessary... kill
> > -SIGSTOP works, right?]
>
> Not always. Take for example the case where you have an NFS mount and
> happen to be doing an ls when the suspend cycle is started. If you
> signal the NFSd threads before the ls thread, the NFS threads will
> refrigerate okay, but the ls thread will fail to stop because it's
> waiting for data from the nfsd threads.
Hmm, you are right that with dead nfs server, kill -SIGSTOP will fail
on ls, and similary current refrigerator will fail. I think we can
live with that.
I agree that two-stage suspend is probably neccessary (userland first,
kernel than); but that should be possible without that big changes,
right?
> The best way to test the reliability of the current freezer
> implementation is to grab Michael's test patches. They can load the
> system down with NFS access, kernel compiles, benchmarks and so on.
> You'll quickly see the freezer fail. My implementation handles those
> loads flawlessly, and where problems are found, they're easily fixed.
Your solution is more reliable, thats right.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
next prev parent reply other threads:[~2004-03-16 10:17 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-03-15 19:54 Pavel Machek
2004-03-15 20:53 ` Andrew Morton
2004-03-15 20:57 ` Pavel Machek
2004-03-15 21:21 ` Andrew Morton
2004-03-15 19:38 ` Nigel Cunningham
2004-03-15 21:53 ` Andrew Morton
2004-03-15 20:14 ` Nigel Cunningham
2004-03-16 0:56 ` Pavel Machek
2004-03-15 23:27 ` Nigel Cunningham
2004-03-16 10:17 ` Pavel Machek [this message]
2004-03-16 19:37 ` Nigel Cunningham
2004-03-16 1:32 ` Fedor Karpelevitch
[not found] ` <20040316091648.GB6301@pern.dea.icai.upco.es>
2004-03-16 10:11 ` Pavel Machek
2004-03-18 8:00 ` Romano Giannetti
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=20040316101715.GA2175@elf.ucw.cz \
--to=pavel@ucw.cz \
--cc=akpm@osdl.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@digitalimplant.org \
--cc=ncunningham@users.sourceforge.net \
/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®