Re: [LSF/MM TOPIC] Phasing out kernel thread freezing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Feb 25, 2018 at 6:22 PM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote:
> On Sun, Feb 25, 2018 at 10:45:26AM +0100, Rafael J. Wysocki wrote:
>> On Sat, Feb 24, 2018 at 4:27 AM, Luis R. Rodriguez <mcgrof@xxxxxxxxxx> wrote:
>> > On Mon, Feb 05, 2018 at 09:28:37AM +0100, Rafael J. Wysocki wrote:
>> >> Moreover, during hibernation devices are suspended for two times (and
>> >> resumed in between, of course) whereas filesystems only need to be
>> >> "suspended" once.
>> >
>> > From your point of view yes, but actually internally the VFS layer or
>> > filesystems themselves may end up re-using this mechanism later for
>> > other things like -- snapshotting. And if some folks have it the way
>> > they want it, we may need a dependency map between filesystems anyway
>> > for filesystem specific reasons.
>>
>> That's orthogonal to what I said.
>
> <-- snip -->
>
>> However, *devices* are resumed after creating the image so that the
>> image itself can be written to persistent storage and are suspended
>> after that again before putting the system to sleep (for wakeup to
>> work, among other things).
>>
>> That's why suspend/resume of filesystems cannot be tied to
>> suspend/resume of devices.
>
> Ah, yes, I see your point now. So for filesystems we really don't
> care if its suspend or hibernation, we just need to freeze in the right
> order. So long as we get that order right we should be OK.

Generally, yes.

System suspend/resume (S2R, S2I), however, doesn't really require the
flushing part, so in principle the full-blown fs freezing is not
necessary in that case, strictly speaking.  The ordering of writes
still has to be preserved in this case (that is, writes to persistent
storage in the presence of a suspend-resume cycle must occur in the
same order as without the suspend-resume), but it doesn't matter too
much when the writes actually happen.  They may be carried out before
the suspend or after the resume or somewhere during one of them: all
should be fine so long as the ordering of writes doesn't change as a
result of the suspend-resume (and suspend-resume failures are like
surprise resets from the fs perspective in that case, so journaling
should be sufficient to recover from them).

Of course, the full-blown freezing will work for system suspend too,
but it may be high-latency which is not desirable in some scenarios
utilizing system suspend/resume ("dark resume" or "lucid sleep"
scenarios, for example).  That will be a concern in the long run (it
kind of is a concern already today), so I would consider
special-casing it from the outset.

> Curious --  do we resume *all* devices after creating the image for hibernation
> today?

Yes, we do.

It is not straightforward to determine which devices will be necessary
to save the image in general and we would need to resume a significant
subset of the device hierarchy for this purpose anyway.

Thanks,
Rafael



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux