RE: [PATCH V10 0/6] mm: frontswap: overview (and proposal to merge atnext window)

[Dan Magenheimer]

> From: KAMEZAWA Hiroyuki [mailto:kamezawa.hiroyu@xxxxxxxxxxxxxx]
> Sent: Wednesday, September 28, 2011 10:48 PM
> 
> On Wed, 28 Sep 2011 07:09:18 -0700 (PDT)
> Dan Magenheimer <dan.magenheimer@xxxxxxxxxx> wrote:
> 
> > > From: KAMEZAWA Hiroyuki [mailto:kamezawa.hiroyu@xxxxxxxxxxxxxx]
> > > Sent: Wednesday, September 28, 2011 12:16 AM
> > >
> > > I'm sorry I couldn't catch following... what happens at hibernation ?
> > > frontswap is effectively stopped/skipped automatically ? or contents of
> > > TMEM can be kept after power off and it can be read correctly when
> > > resume thread reads swap ?
> > >
> > > In short: no influence to hibernation ?
> > > I'm sorry if I misunderstand some.
> >
> > Hibernation would need to be handled by the tmem backend (e.g. zcache, Xen
> > tmem).  In the case of Xen tmem, both save/restore and live migration are
> > fully supported.  I'm not sure if zcache works across hibernation; since
> > all memory is kmalloc'ed, I think it should work fine, but it would be an
> > interesting experiment.
> 
> I'm afraid that users will lose data on memory of frontswap/zcache/tmem
> by power-off, hibernation. How about adding internal hooks to disable/sync
> frontswap itself before hibernation ? difficult ?

Hi Kame --

First, remember that frontswap is currently only enabled by
specifying a tmem backend as a kernel boot parameter ("zcache"
or "tmem"), so there is no risk of data loss to the average
laptop user doing hibernation, even if CONFIG_FRONTSWAP
and CONFIG_ZCACHE are enabled in their kernel.

The patchset's frontswap_shrink() call can be used to remove
pages from frontswap so there is one internal hook for this
already.

I still think hibernation should work fine with zcache
because all frontswap metadata and data is preserved as part
of kernel memory.  For poweroff, the normal swapoff will
"get" all frontswap pages, so no issue there either.
I do agree that this should be investigated before zcache
could be moved from staging and certainly before zcache is
enabled by default by a distro (with no kernel boot parameter).
If it turns out that zcache needs more hooks to provide finer
control of frontswap disable/sync, I don't think it will be 
difficult but I think those hooks should be designed in the future.

And Xen tmem supports save/restore and live migration
already so this is not a concern for the Xen tmem backend.

Hope that helps!

Thanks,
Dan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/