Hi Andrew et al.
The following patches suppress various actions and errors while we're
suspending.
Patch 1 disables the OOM killer and patch 3 complaining when no memory
is available for an allocation. These are needed because swsusp and
suspend2 both reduce the size of an image by allocating all the memory
they can get, thus inciting the vm to free/swap out memory. This in turn
can lead to processes being OOM killed and/or errors in the logs about
not being able to allocate pages.
Patch 2 disables the SMP call for flushing tlbs while we have other SMP
processors frozen. It is needed because while making and restoring our
atomic copy of the image, we freeze other processors (call an smp
function in which they spin) while atomically mapping highmem pages and
copying data. If we tried to flush tlbs on other processors at this
point, we would deadlock. We thus only flush local tlbs and leave other
processors to flush their local tlbs when exiting from the freezer
function.
Patch 4 disables pdflush during suspend. It needs special handling
because it runs off a timer, which we want to keep going while
supressing the actual work. We don't want to pdflush to run because it
may cause pages overwritten with the image to be synced to disk, thus
corrupting the drive image if the user uses noresume later (if they
don't, the original data is restored and no damage is done. Better safe
than sorry though).
Patch 5 disables slab reaping during suspend in a similar manner, but
for different reasons. The reaping can lead to inconsistencies in the
image and thus crashes post-resume. It is needed mainly because we don't
make a single atomic snapshot, but instead save the LRU pages
separately. I have to admit I don't fully understand the link, but this
makes the difference.
Regards,
Nigel
--
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901
Many today claim to be tolerant. True tolerance, however, can cope with others
being intolerant.
Nigel Cunningham <[email protected]> wrote:
>
> The following patches suppress various actions and errors while we're
> suspending.
Sorry, I'm not in a position to merge all this stuff up.
There's a significant rewrite of the suspend code in -mm and we're having
trouble getting that merged up because Pat has limited time to work on
these things.
Until we get the existing rework settled and Pat has time to look at
suspend2 I'd rather not have to take it on.
Hi.
On Fri, 2004-09-17 at 10:00, Andrew Morton wrote:
> Nigel Cunningham <[email protected]> wrote:
> >
> > The following patches suppress various actions and errors while we're
> > suspending.
>
> Sorry, I'm not in a position to merge all this stuff up.
>
> There's a significant rewrite of the suspend code in -mm and we're having
> trouble getting that merged up because Pat has limited time to work on
> these things.
>
> Until we get the existing rework settled and Pat has time to look at
> suspend2 I'd rather not have to take it on.
Fair enough. Shall I just post the remainder to LKML for now, get it
reviewed and apply the changes? Then, when everyone is happy and Patrick
has done his stuff, I could simply ask you to pull from
suspend.bkbits.net.
Regards,
Nigel
--
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901
Many today claim to be tolerant. True tolerance, however, can cope with others
being intolerant.
Nigel Cunningham <[email protected]> wrote:
>
> > Until we get the existing rework settled and Pat has time to look at
> > suspend2 I'd rather not have to take it on.
>
> Fair enough. Shall I just post the remainder to LKML for now, get it
> reviewed and apply the changes? Then, when everyone is happy and Patrick
> has done his stuff, I could simply ask you to pull from
> suspend.bkbits.net.
That works for me.
Hi.
On Fri, 2004-09-17 at 10:23, Andrew Morton wrote:
> Nigel Cunningham <[email protected]> wrote:
> >
> > > Until we get the existing rework settled and Pat has time to look at
> > > suspend2 I'd rather not have to take it on.
> >
> > Fair enough. Shall I just post the remainder to LKML for now, get it
> > reviewed and apply the changes? Then, when everyone is happy and Patrick
> > has done his stuff, I could simply ask you to pull from
> > suspend.bkbits.net.
Err. suspend2.bkbits.net/merge-tree.
> That works for me.
Okay then. Do you want me to continue to copy you while sending the
patches, or only send to LKML?
Regards,
Nigel
--
Nigel Cunningham
Pastoral Worker
Christian Reformed Church of Tuggeranong
PO Box 1004, Tuggeranong, ACT 2901
Many today claim to be tolerant. True tolerance, however, can cope with others
being intolerant.
Hi!
> The following patches suppress various actions and errors while we're
> suspending.
>
> Patch 1 disables the OOM killer and patch 3 complaining when no memory
> is available for an allocation. These are needed because swsusp and
> suspend2 both reduce the size of an image by allocating all the memory
> they can get, thus inciting the vm to free/swap out memory. This in turn
> can lead to processes being OOM killed and/or errors in the logs about
> not being able to allocate pages.
swsusp1 has some less ugly solution that is able to free memory but
not provoke OOM killer. I guess you should use it and drop this patch.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!