LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Alan Stern <stern@rowland.harvard.edu>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: rjw@sisk.pl, <linux-kernel@vger.kernel.org>,
	<ncunningham@crca.org.au>, <linux-pm@lists.linux-foundation.org>
Subject: Re: [linux-pm] Freezer: Don't count threads waiting for frozen filesystems.
Date: Wed, 29 Oct 2008 09:51:34 -0400 (EDT)	[thread overview]
Message-ID: <Pine.LNX.4.44L0.0810290944240.2515-100000@iolanthe.rowland.org> (raw)
In-Reply-To: <E1Kv688-0007Kp-SN@pomaz-ex.szeredi.hu>

On Wed, 29 Oct 2008, Miklos Szeredi wrote:

> Not all callbacks.  I don't know what the current model is but AFAIR
> it should be something like this:
> 
>   1) call drivers to prepare for suspend (allocate space, etc)
>   2) stop all driver activity (plug queues, disable interrupts, etc)
>   3) call drivers to actually save state and power down
>   4) suspend
> 
> The part we are concerned is stopping driver activity.  It could be
> done with a mutex, or it could be done by freezing tasks.  Adding a
> mutex or other mechanism is the one I most like, but it's probably the
> biggest work, so lets look at how to fix the freezing:

Not only is adding a mutex the biggest amount of work, it has has the 
largest impact.  Every I/O pathway would have to acquire the 
appropriate mutex.  That's a significant additional load on the system.

> Currently the criteria for freezing is that userspace task has to exit
> kernelspace, and kernel task has to hit a specific "freeze point".
> This causes problems where we want to freeze tasks which are "stuck"
> inside filesystems or other non-driver parts of the kernel.  We can
> fix this two ways:
> 
>   a) mark additional places to freeze for userspace tasks as
>   well. This is the direction Nigel seems to be taking.
> 
>   b) or instead we could allow freezing anywhere in uninterruptible
>   sleep, _except_ where explicity marked.
> 
> Which is easier?  I don't know.  But I very storgly feel that marking
> un-freezable places instead of marking freezable places is a much
> cleaner solution.  It only affects parts of the kernel which have
> something to do with suspend, instead of affecting parts of the kernel
> which have absolutely nothing to do with suspend.

The problem with unrestricted freezing shows up when you freeze tasks
that hold a mutex or other sort of lock.  If this mutex is needed later
on for suspending a device then the suspend will hang, because a frozen
task can't release any mutexes.

I suppose you could try to categorize mutexes as "freezable" and 
"non-freezable".  Ones used by device drives would generally be 
non-freezable, whereas others (such as those used by VFS) would be 
freezable.  Still, it would be pretty difficult.  Among other things, 
it would be necessary to verify that a task holding a non-freezable 
mutex never tries to acquire a freezable mutex.

Alan Stern


  reply	other threads:[~2008-10-29 13:51 UTC|newest]

Thread overview: 59+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1224886068.6478.21.camel@nigel-laptop>
2008-10-26 20:01 ` Rafael J. Wysocki
2008-10-27 11:12   ` Miklos Szeredi
2008-10-27 11:20     ` Nigel Cunningham
2008-10-27 11:37       ` Rafael J. Wysocki
2008-10-27 11:40         ` Nigel Cunningham
2008-10-27 12:38           ` Miklos Szeredi
2008-10-27 20:59             ` Nigel Cunningham
2008-10-27 21:09               ` Miklos Szeredi
2008-10-27 22:13                 ` Nigel Cunningham
2008-10-28 20:25                   ` Miklos Szeredi
2008-10-28 21:29                     ` Nigel Cunningham
2008-10-28 21:51                       ` Miklos Szeredi
2008-10-28 22:00                         ` Rafael J. Wysocki
2008-10-28 22:02                           ` Miklos Szeredi
2008-10-28 22:21                             ` Rafael J. Wysocki
2008-10-28 23:21                               ` Miklos Szeredi
2008-10-28 23:59                                 ` Rafael J. Wysocki
2008-10-29  8:10                                   ` Miklos Szeredi
2008-10-29 13:51                                     ` Alan Stern [this message]
2008-10-29 14:50                                       ` Miklos Szeredi
2008-10-29 15:28                                         ` Alan Stern
2008-10-29 15:50                                           ` Miklos Szeredi
2008-10-29 16:17                                             ` Alan Stern
2008-10-29 16:10                                           ` Miklos Szeredi
2008-10-29 20:37                                             ` Alan Stern
2008-10-29 21:11                                               ` Rafael J. Wysocki
2008-10-29 21:45                                                 ` Nigel Cunningham
2008-10-29 22:07                                                   ` Rafael J. Wysocki
2008-10-29 23:53                                                     ` Miklos Szeredi
2008-11-09 13:44                                                       ` Pavel Machek
2008-10-29 23:48                                                   ` Miklos Szeredi
2008-10-30 13:04                                                     ` Nigel Cunningham
2008-10-30 13:56                                                       ` Alan Stern
2008-10-30 21:44                                                         ` Nigel Cunningham
2008-10-31  8:49                                                           ` Miklos Szeredi
2008-10-31  9:10                                                             ` Nigel Cunningham
2008-10-31  9:16                                                               ` Miklos Szeredi
2008-10-31 11:28                                                                 ` Nigel Cunningham
2008-10-31 12:44                                                                   ` Miklos Szeredi
2008-10-31 21:11                                                                     ` Nigel Cunningham
2008-10-29 23:43                                               ` Miklos Szeredi
2008-10-30 13:54                                                 ` Alan Stern
2008-10-30 14:39                                                   ` Miklos Szeredi
2008-10-30 17:07                                                     ` Alan Stern
2008-10-30 17:43                                                       ` Miklos Szeredi
2008-10-30 20:17                                                     ` Rafael J. Wysocki
2008-11-15 16:58                                                     ` Pavel Machek
2008-10-29 23:56                                               ` Matthew Garrett
2008-10-28 22:03                         ` Nigel Cunningham
2008-10-28 23:04                     ` Nigel Cunningham
2008-10-28 23:12                       ` Miklos Szeredi
2008-10-28 23:17                         ` Nigel Cunningham
2008-10-28 23:24                           ` Miklos Szeredi
2008-10-28 23:41                             ` Nigel Cunningham
2008-10-28 23:45                               ` Miklos Szeredi
2008-10-28 23:50                                 ` Miklos Szeredi
2008-10-28 23:58                                   ` Nigel Cunningham
2008-10-28 23:54                                 ` Nigel Cunningham
2008-10-27 11:37       ` Miklos Szeredi

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=Pine.LNX.4.44L0.0810290944240.2515-100000@iolanthe.rowland.org \
    --to=stern@rowland.harvard.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@lists.linux-foundation.org \
    --cc=miklos@szeredi.hu \
    --cc=ncunningham@crca.org.au \
    --cc=rjw@sisk.pl \
    --subject='Re: [linux-pm] Freezer: Don'\''t count threads waiting for frozen filesystems.' \
    /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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).