public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Nigel Cunningham <ncunningham@linuxmail.org>
To: Pavel Machek <pavel@ucw.cz>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Merging the Suspend2 freezer implementation.
Date: Wed, 09 Feb 2005 08:59:59 +1100	[thread overview]
Message-ID: <1107899999.4330.39.camel@desktop.cunninghams> (raw)
In-Reply-To: <20050208163644.GG1622@elf.ucw.cz>

Hi.

On Wed, 2005-02-09 at 03:36, Pavel Machek wrote:
> Hi!
> 
> > I'm keen to see if we can merge Suspend2's freezer implementation after
> > 2.6.11. Does that conflict with any of your intended changes? If it
> > doesn't, I'll submit a patch for review/merge as quickly as I can.
> 
> Freezer is very independend, and no, I do not plan any changes in that area.

Ok.

> > The main change involves the introduction of a new SYNCTHREAD flag. We
> > use this to avoid deadlocking over processes that are running sys_sync
> > and siblings. Processes that enter those routines get the flag added,
> > and it's removed when they exit the sync routine. We then freeze in four
> > stages: 
> 
> Is SYNCTHREAD neccessary for me, too, or is it needed for suspend2, only?

It's necessary for reliable freezing under I/O load. Signalling the
non-sync threads first removes the race involved in some threads
submitting I/O while others are trying to sync. Try doing a dd and a
sync at the same time. The sync can take ages to return, worst case,
sometimes not until the dd is completed. (Actually, try doing anything
while a dd is running :>)

> > 1) Freeze user space threads without SYNCTHREAD set;
> > 2) Freeze user space threads with SYNCTHREAD set;
> > 3) Run our own sys_sync in case no one else was syncing
> > 4) Freeze kernel space threads without NOFREEZE set.
> > 
> > I'd also like to look at your SMP support and see if we can improve
> > compatibility there at the same time.
> 
> Why not... But parts of smp support really need to be in assembly, and
> they are not, neither in swsusp nor in suspend2...

I don't think there's any issue here - or at least not a significant
one. I've had SMP support for just over a year, and I don't believe
there are any outstanding SMP specific issues in the freezer code (or
anywhere else in suspend2). All the resuming failures people get with
Suspend2 are traceable to device drivers (usb, dri/drm, cpufreq,
8139too, e1000 cards...)

> > Finally I'd like to merge the support for freezer flags on workqueues.

No comment here? :>

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com

Ph: +61 (2) 6292 8028      Mob: +61 (417) 100 574


  reply	other threads:[~2005-02-08 21:57 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-02-08  0:23 Merging the Suspend2 freezer implementation Nigel Cunningham
2005-02-08 16:36 ` Pavel Machek
2005-02-08 21:59   ` Nigel Cunningham [this message]
2005-02-08 22:32     ` Pavel Machek
2005-02-08 22:38       ` Nigel Cunningham

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=1107899999.4330.39.camel@desktop.cunninghams \
    --to=ncunningham@linuxmail.org \
    --cc=linux-kernel@vger.kernel.org \
    --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