From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
To: Jiri Kosina <jkosina@suse.com>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [TECH TOPIC] giving freezer well-defined semantics
Date: Sat, 11 Jul 2015 15:22:00 +1000 [thread overview]
Message-ID: <1436592120.3948.168.camel@kernel.crashing.org> (raw)
In-Reply-To: <alpine.LNX.2.00.1507071340480.10183@pobox.suse.cz>
On Tue, 2015-07-07 at 22:42 +0200, Jiri Kosina wrote:
> Tejun came up with a different aproach at [1] -- basically getting rid of
> the freezer completely, and rather annotating those I/O requests which are
> needed for writing the hibernation image out, so that they make it through
> all the affected subsystems, while other I/O requests would be frozen.
>
> This would be rather dramatic change both in a way how kthreads work, how
> hibernation works, and it'd be necessary to have means to mark I/O
> requests as "needed for hibernation", therefore I think this would be a
> good cross-subsystem topic.
I like that approach. In the early days, when we put together what
eventually became our power management, I was against the freezer to
begin with :-) I always had the feeling that it was an incomplete band
aid which was mostly trying to hide the problem rather than solve it.
In part because just stopping threads isn't a guarantee that things
stop, "driver" requests can be issued in theory from anything such as
timers, external interrupts, etc... threads are only part of the
problem. It's also non obvious whether a given thread is needed to write
the suspend image or not. A single thread can have multiple behaviours
associated with it. It can monitor link health and be necessary for
keeping things working but can also deal with hotplug which might not be
desirable.
So all in all, I agree with Tejun.
Cheers,
Ben.
prev parent reply other threads:[~2015-07-11 5:22 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-07 20:42 Jiri Kosina
2015-07-07 21:32 ` Rafael J. Wysocki
2015-07-07 21:13 ` Jiri Kosina
2015-07-07 23:12 ` Rafael J. Wysocki
2015-07-08 8:16 ` Jiri Kosina
2015-07-08 21:55 ` Rafael J. Wysocki
2015-07-09 11:25 ` Jan Kara
2015-07-10 0:18 ` Rafael J. Wysocki
2015-07-11 5:22 ` Benjamin Herrenschmidt [this message]
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=1436592120.3948.168.camel@kernel.crashing.org \
--to=benh@kernel.crashing.org \
--cc=jkosina@suse.com \
--cc=ksummit-discuss@lists.linuxfoundation.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