From: "Rafael J. Wysocki" <rjw@sisk.pl>
To: suspend-devel@lists.sourceforge.net
Cc: pm list <linux-pm@lists.osdl.org>,
Alan Stern <stern@rowland.harvard.edu>,
Pavel Machek <pavel@ucw.cz>
Subject: Re: [linux-pm] [RFC][PATCH -mm 1/5] PM: Make freeze_processes SMP-safe
Date: Thu, 30 Nov 2006 17:04:16 +0100 [thread overview]
Message-ID: <200611301704.17456.rjw@sisk.pl> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0611301033440.3204-100000@iolanthe.rowland.org>
On Thursday, 30 November 2006 16:43, Alan Stern wrote:
> On Thu, 30 Nov 2006, Rafael J. Wysocki wrote:
>
> > In fact, I really mean that if we want a process to go to the refrigerator, we
> > have to set PF_FREEZE for it (otherwise try_to_freeze() won't do anytning).
> > Thus because we want stopped processes to go to the refrigerator once they
> > have received the continuation signal, we have to set PF_FREEZE for them,
> > so we should call either freeze_process() or just freeze() for them.
> >
> > Now once we have set PF_FREEZE for a stopped process, we shouldn't count
> > it as freezeable any more, because we can't do anything more with it.
> > Moreover, if the process hasn't received the continuation signal before we
> > call freeze_processes(), PF_FREEZE set will still be set for it, so we have to
> > clear it (otherwise the process would go to the refrigerator as soon as it
> > receives the continuation signal).
>
> I haven't followed the patches, but this obviously is a very tricky issue.
Yes.
> A stopped process might be waiting for a signal or event that can be sent
> only by another process which is already frozen -- in which case the
> stopped process is itself effectively frozen without your doing anything
> to it.
Yes.
> On the other hand, a stopped process might be waiting for a signal that
> can be sent by an unfreezable process -- and the stopped process might be
> holding a lock which is needed by some other unfreezable process, so you
> need to allow it to run long enough to release the lock before freezing
> it.
Theoretically, yes. But does it happen? Moreover, even if it does, why can't
we hold the unfreezeable process until the lock is released?
> Unless you can somehow rule out this scenario (unfreezable process waiting
> for resource held by unfrozen but stopped and freezable process), I don't
> see how this approach can be made to work.
Well, currently we're treating all stopped processes as non-freezeable. This
also is theoretically wrong, because, for example, the continuation signal may
be delivered to a stopped userland proces after we have frozen all of the
other userland processes, so we won't be freezing this one and it'll be
allowed to run when we are saving the image, which is generally dangerous.
I also haven't seen it happening, though.
Thus there are two theoretical issues on the table, but I think the
probability of the second one actually happening is a bit greater.
Greetings,
Rafael
--
You never change things by fighting the existing reality.
R. Buckminster Fuller
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
next prev parent reply other threads:[~2006-11-30 16:04 UTC|newest]
Thread overview: 48+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-25 21:10 [RFC][PATCH -mm] PM: Change ordering of suspend and resume code Rafael J. Wysocki
2006-11-25 21:29 ` [RFC][PATCH -mm 1/5] PM: Make freeze_processes SMP-safe Rafael J. Wysocki
2006-11-26 7:47 ` Pavel Machek
2006-11-26 10:02 ` Rafael J. Wysocki
2006-11-26 11:15 ` Rafael J. Wysocki
2006-11-26 13:34 ` Rafael J. Wysocki
2006-11-26 19:48 ` Pavel Machek
2006-11-26 23:09 ` Rafael J. Wysocki
2006-11-26 23:28 ` Pavel Machek
2006-11-27 2:41 ` [linux-pm] " Alan Stern
2006-11-27 20:04 ` Rafael J. Wysocki
2006-11-27 10:50 ` Pavel Machek
2006-11-27 20:02 ` Rafael J. Wysocki
2006-11-29 23:56 ` Pavel Machek
2006-11-28 23:40 ` Rafael J. Wysocki
2006-11-29 23:55 ` Pavel Machek
2006-11-30 0:21 ` Rafael J. Wysocki
2006-11-30 15:07 ` Rafael J. Wysocki
2006-11-30 15:43 ` [linux-pm] " Alan Stern
2006-11-30 16:04 ` Rafael J. Wysocki [this message]
2006-11-30 19:23 ` Rafael J. Wysocki
2006-11-30 22:34 ` Alan Stern
2006-11-30 22:57 ` Rafael J. Wysocki
2006-12-01 14:56 ` Alan Stern
2006-12-01 19:57 ` Rafael J. Wysocki
2006-12-01 21:17 ` Alan Stern
2006-12-01 21:19 ` Rafael J. Wysocki
2006-12-01 22:07 ` Alan Stern
2006-12-01 23:38 ` Rafael J. Wysocki
2006-12-02 11:55 ` Pavel Machek
2006-12-02 15:39 ` Alan Stern
2006-12-03 11:17 ` Rafael J. Wysocki
2006-11-30 21:55 ` [Suspend-devel] " Rafael J. Wysocki
2006-11-26 19:45 ` [linux-pm] " Pavel Machek
2006-11-26 23:37 ` Luca
2006-11-25 21:34 ` [RFC][PATCH -mm 2/5] swsusp: Change code ordering in disk.c Rafael J. Wysocki
2006-11-25 21:38 ` [RFC][PATCH -mm 3/5] swsusp: Change code ordering in user.c Rafael J. Wysocki
2006-11-25 21:45 ` [RFC][PATCH -mm 4/5] swsusp: Add PLATFORM_SNAPSHOT and PLATFORM_RESTORE ioctls Rafael J. Wysocki
2006-11-26 19:51 ` [linux-pm] " Pavel Machek
2006-11-26 23:12 ` Rafael J. Wysocki
2006-11-26 23:29 ` Pavel Machek
2006-11-27 10:37 ` Pavel Machek
2006-11-25 21:49 ` [RFC][PATCH -mm 5/5] PM: Change code ordering in main.c Rafael J. Wysocki
2006-11-26 7:44 ` [RFC][PATCH -mm] PM: Change ordering of suspend and resume code Pavel Machek
2006-11-26 10:08 ` Rafael J. Wysocki
2006-11-26 21:31 ` Pavel Machek
2006-11-26 23:15 ` Rafael J. Wysocki
2006-11-30 14:02 ` Stefan Seyfried
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=200611301704.17456.rjw@sisk.pl \
--to=rjw@sisk.pl \
--cc=linux-pm@lists.osdl.org \
--cc=pavel@ucw.cz \
--cc=stern@rowland.harvard.edu \
--cc=suspend-devel@lists.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