Prev: [PATCH 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
Next: [GIT PULL] iBFT features for v2.6.36
From: Rafael J. Wysocki on 2 Aug 2010 10:30
On Monday, August 02, 2010, KAMEZAWA Hiroyuki wrote:
> On Fri, 30 Jul 2010 13:14:32 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)jp.fujitsu.com> wrote:
>
> > On Thu, 29 Jul 2010 21:10:10 -0700
> > Hugh Dickins <hughd(a)google.com> wrote:
> >
> > > On Thu, Jul 29, 2010 at 5:01 PM, KAMEZAWA Hiroyuki
> > > <kamezawa.hiroyu(a)jp.fujitsu.com> wrote:
> > >
> > > > I think the best way is kexec(). But maybe rollback from hibernation failure
> > > > will be difficult. Considering how crash-dump works well and under maintainance
> > > > by many enterprise guys, hibernation-by-kexec is a choice. I think. It can make
> > > > reuse of kdump code, ...or, hibernation-resume code can eat kdump image
> > > > directly. Maybe the problem will be the speed of dump.
> > >
> > > I've no appetite for a total rework of hibernation, and I don't see
> > > how that would
> > > address the issue: I'm just looking for some protection against swap
> > > reuse danger.
> > >
> > Okay ;) (And I forget that kexec has to prepare memory at boot time for 2nd kernel.
> > It will be harmful for small device guys.)
> >
> > I'll prepare a routine not-quick-fix.
>
> Ok, here. Passed easy tests as
> # echo disk > /sys/power/state
>
>
> Looks like a big hammer ? But I think following kind of patch is required.
> About swap-reuse, it's only possible when a page is added to swap cache
> but try_to_unmap() fails and the page remains in memory. IIUC, most of this
> kind of pages will be backed to swap by shrink_all_memory(). So, reuse-swap
> happens only when the user unlucky. This patch ignores reuse-swap but freeze
> swap_map[] for saving swap_map[] to the disk in consistent way.
>
> ==
> From: KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)jp.fujitsu.com>
>
> swap_map[] is a one of objects which can be update while hibernation. I.E,
> usage counter in swap_map[] is updated while hibernation is making a copy
> of memory image to the disk.
>
> At resume, hibenation code doesn't call swap_free() against the swaps they
> used...So, the swap_map[] will turns to be an initial state.
>
> With small consideration, the question is how swap_map[] updated before
> dumping to the disk is treated. In swap-system view, there are no guarantee
> that swap_map[] are properly reloaded and there is no leak in swap count.
>
> This patch tries to freeze swap_map[] during hibernation.
> By this, no updates will be happen to swap_map[] among save_image().
> At load_image(), the swap_map[] has no record for swap entries used by
> save_image(), we can simply forget it.
>
> Note: I'm not a specialist of hibernation...so, I'm not sure the hooks
> to kernel/power/user.c is appropriate or not.
> And this disables swap-out once hibernation starts saving.
> Should we afraid of OOM ?

OOM shoiuld not happen at that time, so no worry.

I'll have a deeper look into the patch later today.

Thanks,
Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Rafael J. Wysocki on 3 Aug 2010 19:20
On Monday, August 02, 2010, KAMEZAWA Hiroyuki wrote:
> On Fri, 30 Jul 2010 13:14:32 +0900
> KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)jp.fujitsu.com> wrote:
>
> > On Thu, 29 Jul 2010 21:10:10 -0700
> > Hugh Dickins <hughd(a)google.com> wrote:
> >
> > > On Thu, Jul 29, 2010 at 5:01 PM, KAMEZAWA Hiroyuki
> > > <kamezawa.hiroyu(a)jp.fujitsu.com> wrote:
> > >
> > > > I think the best way is kexec(). But maybe rollback from hibernation failure
> > > > will be difficult. Considering how crash-dump works well and under maintainance
> > > > by many enterprise guys, hibernation-by-kexec is a choice. I think. It can make
> > > > reuse of kdump code, ...or, hibernation-resume code can eat kdump image
> > > > directly. Maybe the problem will be the speed of dump.
> > >
> > > I've no appetite for a total rework of hibernation, and I don't see
> > > how that would
> > > address the issue: I'm just looking for some protection against swap
> > > reuse danger.
> > >
> > Okay ;) (And I forget that kexec has to prepare memory at boot time for 2nd kernel.
> > It will be harmful for small device guys.)
> >
> > I'll prepare a routine not-quick-fix.
>
> Ok, here. Passed easy tests as
> # echo disk > /sys/power/state
>
>
> Looks like a big hammer ? But I think following kind of patch is required.
> About swap-reuse, it's only possible when a page is added to swap cache
> but try_to_unmap() fails and the page remains in memory. IIUC, most of this
> kind of pages will be backed to swap by shrink_all_memory(). So, reuse-swap
> happens only when the user unlucky. This patch ignores reuse-swap but freeze
> swap_map[] for saving swap_map[] to the disk in consistent way.
>
> ==
> From: KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)jp.fujitsu.com>
>
> swap_map[] is a one of objects which can be update while hibernation. I.E,
> usage counter in swap_map[] is updated while hibernation is making a copy
> of memory image to the disk.
>
> At resume, hibenation code doesn't call swap_free() against the swaps they
> used...So, the swap_map[] will turns to be an initial state.
>
> With small consideration, the question is how swap_map[] updated before
> dumping to the disk is treated. In swap-system view, there are no guarantee
> that swap_map[] are properly reloaded and there is no leak in swap count.
>
> This patch tries to freeze swap_map[] during hibernation.
> By this, no updates will be happen to swap_map[] among save_image().
> At load_image(), the swap_map[] has no record for swap entries used by
> save_image(), we can simply forget it.
>
> Note: I'm not a specialist of hibernation...so, I'm not sure the hooks
> to kernel/power/user.c is appropriate or not.
> And this disables swap-out once hibernation starts saving.
> Should we afraid of OOM ?
>
> Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu(a)jp.fujitsu.com>

I have only one comment (below).

> ---
....
> Index: mmotm-0727/kernel/power/user.c
> ===================================================================
> --- mmotm-0727.orig/kernel/power/user.c
> +++ mmotm-0727/kernel/power/user.c
> @@ -135,6 +135,7 @@ static int snapshot_release(struct inode
> free_basic_memory_bitmaps();
> data = filp->private_data;
> free_all_swap_pages(data->swap);
> + hibernation_thaw_swap();

free_all_swap_pages() calls hibernation_thaw_swap(), so it doesn't need to be
called again.

> if (data->frozen)
> thaw_processes();
> pm_notifier_call_chain(data->mode == O_WRONLY ?
>
>
> --

Rafael
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
 | 
Pages: 1
Prev: [PATCH 1/2 block#for-linus] bio, fs: update READA and SWRITE to match the corresponding BIO_RW_* bits
Next: [GIT PULL] iBFT features for v2.6.36