linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Ray Bryant <raybry@engr.sgi.com>
To: Kirill Korotaev <dev@sw.ru>
Cc: Christoph Lameter <christoph@lameter.com>,
	linux-mm@kvack.org, linux-kernel@vger.kernel.org, pavel@suse.cz,
	torvalds@osdl.org, raybry@engr.sgi.com,
	lhms <lhms-devel@lists.sourceforge.net>
Subject: Re: [RFC] Fix SMP brokenness for PF_FREEZE and make freezing usable for other purposes
Date: Mon, 27 Jun 2005 02:06:57 -0500	[thread overview]
Message-ID: <42BFA591.1070503@engr.sgi.com> (raw)
In-Reply-To: <1104805430.20050625113534@sw.ru>

Kirill Korotaev wrote:
> CL> The process freezing used by software suspend currently relies on modifying
> current->>flags from outside of the processes context. This makes freezing and
> CL> unfreezing SMP unsafe since a process may change the flags at any time without
> CL> locking. The following patch introduces a new atomic_t field in task_struct
> CL> to allow SMP safe freezing and unfreezing.
> 
> CL> It provides a simple API for process freezing:
> 
> CL> frozen(process)             Check for frozen process
> CL> freezing(process)   Check if a process is being frozen
> CL> freeze(process)             Tell a process to freeze (go to refrigerator)
> CL> thaw_process(process)       Restart process
> 
> CL> I only know that this boots correctly since I have no system that can do
> CL> suspend. But Ray needs an effective means of process suspension for
> CL> his process migration patches.

The process migration patches that Christoph mentions are avaialable at

http://marc.theaimsgroup.com/?l=linux-mm&m=111945947315561&w=2

and subsequent notes to the -mm or lhms-devel lists.  The problem there is
that this code depends on user space code to suspend and then resume the
processes to be migrated before/after the migration.  Christoph suggested
using PF_FREEZE, but I pointed out that was broken on SMP so hence the
current patch.

The idea would be to use PF_FREEZE to cause the process suspension.
A minor flaw in this approach is what happens if a process migration
is in progress when the machine is suspended/resumed.  (Probably not
a common occurrence on Altix... :-), but anyway...).  If the processes
are PF_FROZEN by the migration code, then unfrozen by the resume code,
and then the migration code continues, then we have unstopped processes
being migratated again.  Not a good thing.  On the other hand, the
manual page migration stuff is only existent on NUMA boxes, so the
question is whether any NUMA boxes support suspend/resume.  (Anyone
have a NUMA laptop handy to test this on?   Thought not....)

Is the above scenario even possible?  manual page migration runs as a system
call.  Do system calls all complete before suspend starts?  If that is
the case, then the above is not something to worry about.

The other approach would be to fix the manual page migration code to
handle non-suspended processes, but that hasn't been achieved yet,
in spite of the fact that the underlying page migration code from the
memory hotplug project is designed to support that.  Even then,
there is still a potential race if the migrated application also uses
SIGTOP/SIGCONT, which is how the migrated processes are suspended
today.

Finally, how comfortable are people about using the PF_FREEZE stuff
to start and resume processes for purposes unrelated to suspend/resume?
-- 
Best Regards,
Ray
-----------------------------------------------
                   Ray Bryant
512-453-9679 (work)         512-507-7807 (cell)
raybry@sgi.com             raybry@austin.rr.com
The box said: "Requires Windows 98 or better",
            so I installed Linux.
-----------------------------------------------
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"aart@kvack.org"> aart@kvack.org </a>

  reply	other threads:[~2005-06-27  7:06 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-06-24 20:20 Christoph Lameter
2005-06-24 22:25 ` Nigel Cunningham
2005-06-25  2:51 ` Pavel Machek
2005-06-25  4:31   ` Christoph Lameter
2005-06-25  4:46     ` Nigel Cunningham
2005-06-25 22:37     ` Pavel Machek
2005-06-25  6:13   ` Christoph Lameter
2005-06-26  2:30     ` Pavel Machek
2005-06-26  2:55       ` Christoph Lameter
2005-06-26  3:09         ` Pavel Machek
2005-06-27  3:51           ` Christoph Lameter
2005-06-27  4:21             ` Pavel Machek
2005-06-27  4:24             ` Linus Torvalds
2005-06-27  5:53               ` Christoph Lameter
2005-06-27 14:13                 ` Pavel Machek
2005-06-27 15:13                   ` Christoph Lameter
2005-06-28  6:18                     ` Kirill Korotaev
2005-06-28  7:01                       ` Christoph Lameter
2005-06-28  7:30                         ` Kirill Korotaev
2005-06-28  8:13                           ` Kirill Korotaev
2005-06-28 14:02                             ` Christoph Lameter
2005-06-28 14:01                           ` Christoph Lameter
2005-06-28 12:47                       ` Pavel Machek
2005-07-01 17:06                         ` [SUSPEND 1/2]Replace PF_FREEZE with TIF_FREEZE Christoph Lameter
2005-07-01 17:14                           ` [SUSPEND 2/2] Replace PF_FROZEN with TASK_FROZEN Christoph Lameter
2005-06-28 21:50                 ` [RFC] Fix SMP brokenness for PF_FREEZE and make freezing usable for other purposes Ray Bryant
2005-06-28 21:54                   ` Christoph Lameter
2005-07-03 11:06                     ` Pavel Machek
2005-06-26 10:54       ` Nigel Cunningham
2005-06-25  6:18   ` Christoph Lameter
2005-06-25  7:35 ` Kirill Korotaev
2005-06-27  7:06   ` Ray Bryant [this message]
2005-06-27 13:17     ` Pavel Machek
2005-06-27 14:59       ` Ray Bryant
2005-06-27 18:05         ` 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=42BFA591.1070503@engr.sgi.com \
    --to=raybry@engr.sgi.com \
    --cc=christoph@lameter.com \
    --cc=dev@sw.ru \
    --cc=lhms-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=pavel@suse.cz \
    --cc=torvalds@osdl.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