public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Jiri Kosina <jikos@kernel.org>,
	"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
	Dave Chinner <david@fromorbit.com>, Jan Kara <jack@suse.cz>,
	Christoph Hellwig <hch@lst.de>,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Al Viro <viro@ZenIV.linux.org.uk>, Tejun Heo <tj@kernel.org>,
	linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org,
	linux-pm@vger.kernel.org
Subject: Re: [PATCH 0/3] PM, vfs: use filesystem freezing instead of kthread freezer
Date: Fri, 30 Oct 2015 18:44:17 +0100	[thread overview]
Message-ID: <20151030174417.GA16781@amd> (raw)
In-Reply-To: <Pine.LNX.4.44L0.1510301121340.1659-100000@iolanthe.rowland.org>

On Fri 2015-10-30 11:29:08, Alan Stern wrote:
> On Fri, 30 Oct 2015, Jiri Kosina wrote:
> 
> > This series is a followup to my proposal I brought up on Kernel Summit in 
> > Seoul. Noone seemed to had any principal objections, so let's have wider 
> > audience look into it.
> > 
> > In a nuthsell: freezing of kernel threads is horrible interface with 
> > unclear semantics and guarantees, and I am surprised it ever worked 
> > properly. Plus there are a lot of places that simply use it in a 
> > completely wrong way (which is not suprising, given the lack of defined 
> > semantics and requirements).
> > 
> > I've tested this over a series of suspend/resume cycles on several 
> > machines with at least ext4, btrfs and xfs, and it survived the testing 
> > without any harm.
> > 
> > Patch 1/3 	implements the actual change, and has a more detailed 
> > 		explanation on "why?" and "how?" questions in the changelog
> 
> This patch talks about freezing in relation to hibernation.  What about 
> other forms of suspend?
> 
> Also, it replaces kthread freezing with filesystem freezing.  What 
> about kthreads performing I/O that doesn't go through a filesystem?  
> You write:
> 
> > the only facility that is needed during suspend: "no persistent fs
> > changes are allowed from now on"
> 
> I would say instead "no I/O is allowed from now on".  Maybe that's an 
> overstatement, but I think it comes closer to the truth.

Exactly. And I'm pretty sure hardware drivers do use kernel threads,
and do I/O from them.

LEDs are just one example

Best regards,
								Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  reply	other threads:[~2015-10-30 17:44 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-30 13:47 [PATCH 0/3] PM, vfs: use filesystem freezing instead of kthread freezer Jiri Kosina
2015-10-30 13:47 ` [PATCH 1/3] power, vfs: move away from PF_KTHREAD freezing in favor of fs freezing Jiri Kosina
2015-10-30 14:04   ` kbuild test robot
2015-10-31  8:55   ` Oliver Neukum
2015-11-02  3:01     ` Neil Brown
2015-11-02  7:54   ` yalin wang
2015-11-02 11:05     ` Jiri Kosina
2015-10-30 13:47 ` [PATCH 2/3] freezer: get rid of the kthread freezer Jiri Kosina
2015-10-30 14:08   ` kbuild test robot
2015-10-30 14:12   ` kbuild test robot
2015-10-30 13:48 ` [PATCH 3/3] freezer: warn if anyone is trying to use freezer on kthreads Jiri Kosina
2015-10-30 15:29 ` [PATCH 0/3] PM, vfs: use filesystem freezing instead of kthread freezer Alan Stern
2015-10-30 17:44   ` Pavel Machek [this message]
2015-10-30 19:40     ` Jiri Kosina
2015-10-30 20:41       ` Alan Stern
2015-10-30 21:17         ` Jiri Kosina
2015-10-31  3:15           ` Rafael J. Wysocki
2015-10-31  8:19             ` Jiri Kosina
2015-11-02  2:43               ` Rafael J. Wysocki
2015-11-02 10:45                 ` Jiri Kosina
2015-11-02 11:00                   ` Oliver Neukum
2015-11-02 15:18                   ` Alan Stern
2015-11-03  0:10                 ` Dave Chinner
2015-11-03  4:06                   ` Rafael J. Wysocki
2015-11-03  9:31                   ` Jan Kara
2015-11-03 21:33                     ` Rafael J. Wysocki
2015-10-31 16:01             ` Alan Stern
2015-10-31 15:56           ` Alan Stern

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=20151030174417.GA16781@amd \
    --to=pavel@ucw.cz \
    --cc=david@fromorbit.com \
    --cc=hch@lst.de \
    --cc=jack@suse.cz \
    --cc=jikos@kernel.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=rafael.j.wysocki@intel.com \
    --cc=stern@rowland.harvard.edu \
    --cc=tj@kernel.org \
    --cc=torvalds@linux-foundation.org \
    --cc=viro@ZenIV.linux.org.uk \
    /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