lkml.org 
[lkml]   [2006]   [Jun]   [29]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: [Suspend2][ 07/13] [Suspend2] Page_alloc paranoia.
Date
Hi Nick.

On Friday 30 June 2006 02:22, Nick Piggin wrote:
> Nigel Cunningham wrote:
> > Hi.
> >
> > On Tuesday 27 June 2006 16:11, Nick Piggin wrote:
> >>Nigel Cunningham wrote:
> >>>Add paranoia to the page_alloc code to ensure we don't start page
> >>> reclaim during suspending.
> >>
> >>Nack. Set PF_MEMALLOC if you must.
> >
> > That would work for the thread doing the suspending. What about other
> > kernel threads that might run and allocate memory during the cycle
> > because of $RANDOM_EVENT? We don't want them triggering memory freeing
> > either.
>
> Haven't you suspended the other threads at this point?

Userspace is frozen, but kernel threads are still running. I'm therefore
thinking of allocation of memory by drivers while we're writing the first
part of the image (prior to the atomic copy).

> What are the consequences of allocating memory?

My concern isn't with them allocating any memory, but with the memory
allocation routines trying to enter the vmscan.c routines to free memory.
This would almost certainly free some of the LRU pages we're saving
separately prior to the atomic copy, resulting in an inconsistent image and
crashes and/or on disk corruption post resume. I've recently seen Rafael's
code to take pages off the LRU, and realise that may be a better solution,
but am not sure what adverse side effects it has.

Regards,

Nigel
--
See http://www.suspend2.net for Howtos, FAQs, mailing
lists, wiki and bugzilla info.
[unhandled content-type:application/pgp-signature]
\
 
 \ /
  Last update: 2006-06-30 00:19    [W:0.076 / U:1.428 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site