From: Pavel Machek <pavel@suse.cz>
To: "Rafael J. Wysocki" <rjw@sisk.pl>
Cc: Linux PM <linux-pm@osdl.org>, LKML <linux-kernel@vger.kernel.org>,
Nigel Cunningham <nigel@suspend2.net>
Subject: Re: [RFC][PATCH] swsusp: support creating bigger images
Date: Tue, 25 Apr 2006 00:16:32 +0200 [thread overview]
Message-ID: <20060424221632.GQ3386@elf.ucw.cz> (raw)
In-Reply-To: <200604242355.08111.rjw@sisk.pl>
Hi!
> The appended patch allows swsusp to break the "50% of the normal zone" limit.
> This is achieved by using the observation that pages mapped by frozen
> userland tasks need not be copied before saving.
I've not followed the patch too carefully, but it is not as bad as I
expected...
> With this patch applied I was able to save (and restore ;-)) ~800 MB suspend
> images on a box with 1 GB of RAM.
And did it also work second time? ;-).
Okay, so it can be done, and patch does not look too bad. It still
scares me. Is 800MB image more responsive than 500MB after resume?
I guess we can revert to old behaviour by simply returning 1 from
need_to_copy, right?
I assume that need_to_copy returns 1 in case page is shared by current
and some other process?
> [Please don't beat me very hard, just couldn't resist. ;-)]
Well, you are about to force me to learn about mm internals. Plus you
force everyone who tries to modify swsusp. ... it may be okay if
benefit is great enough and if it gets proper testing. Not 2.6.17
material.
Is benefit worth it?
> --- linux-2.6.17-rc1-mm3.orig/include/linux/rmap.h 2006-04-22 10:34:33.000000000 +0200
> +++ linux-2.6.17-rc1-mm3/include/linux/rmap.h 2006-04-22 10:34:45.000000000 +0200
> @@ -104,6 +104,12 @@ pte_t *page_check_address(struct page *,
> */
> unsigned long page_address_in_vma(struct page *, struct vm_area_struct *);
>
> +#ifdef CONFIG_SOFTWARE_SUSPEND
> +int page_mapped_by_current(struct page *);
> +#else
> +static inline int page_mapped_by_current(struct page *page) { return 0; }
> +#endif /* CONFIG_SOFTWARE_SUSPEND */
I'd leave it undefined. That will prevent nasty surprise when someone
tries to use it w/o CONFIG_SOFTWARE_SUSPEND set.
> @@ -251,6 +253,14 @@ int restore_special_mem(void)
> return ret;
> }
>
> +/* Represents a stacked allocated page to be used in the future */
> +struct res_page {
> + struct res_page *next;
> + char padding[PAGE_SIZE - sizeof(void *)];
> +};
> +
> +static struct res_page *page_list;
> +
> static int pfn_is_nosave(unsigned long pfn)
> {
> unsigned long nosave_begin_pfn = __pa(&__nosave_begin) >>
> PAGE_SHIFT;
Is this part of some other patch?
> @@ -490,6 +613,11 @@ void swsusp_free(void)
> buffer = NULL;
> }
>
> +void swsusp_free(void)
> +{
> + free_image();
> + restore_active_inactive_lists();
> +}
This still scares me. Nice test would be to
save/restore_active_inactive_lists repeatedly in a loop ... on running
system ... aha, but it probably can't work outside of refrigerator?
> case SNAPSHOT_UNFREEZE:
> if (!data->frozen)
> break;
> + if (data->ready) {
> + error = -EPERM;
> + break;
> + }
> down(&pm_sem);
> thaw_processes();
> enable_nonboot_cpus();
Error from UNFREEZE is not nice:
Unfreeze:
unfreeze(snapshot_fd);
return error;
}
... we don't handle it. OTOH I guess it will be all fixed on exit()?
Pavel
--
Thanks for all the (sleeping) penguins.
next prev parent reply other threads:[~2006-04-24 22:16 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-04-24 21:55 [RFC][PATCH] swsusp: support creating bigger images Rafael J. Wysocki
2006-04-24 22:16 ` Pavel Machek [this message]
2006-04-25 8:26 ` Rafael J. Wysocki
2006-04-25 10:04 ` Pavel Machek
2006-04-25 10:31 ` Rafael J. Wysocki
2006-04-27 15:27 ` Rafael J. Wysocki
2006-04-27 20:55 ` Pavel Machek
2006-04-28 9:19 ` Rafael J. Wysocki
2006-04-28 9:23 ` Pavel Machek
2006-04-25 10:28 ` Nick Piggin
2006-04-25 15:39 ` Rafael J. Wysocki
2006-04-25 20:32 ` Pavel Machek
2006-04-25 21:12 ` Rafael J. Wysocki
2006-04-25 21:18 ` Nigel Cunningham
2006-04-25 22:21 ` Rafael J. Wysocki
2006-04-25 22:24 ` Nigel Cunningham
2006-04-25 22:38 ` Rafael J. Wysocki
2006-04-25 22:25 ` Pavel Machek
2006-04-25 22:30 ` Nigel Cunningham
2006-04-25 22:36 ` Pavel Machek
2006-04-25 22:43 ` Rafael J. Wysocki
2006-04-26 0:49 ` Nigel Cunningham
2006-04-30 12:27 ` Rafael J. Wysocki
2006-05-01 1:49 ` Nigel Cunningham
2006-05-01 11:20 ` Rafael J. Wysocki
2006-05-01 22:56 ` Nigel Cunningham
2006-04-26 2:24 ` Nick Piggin
2006-04-26 3:41 ` Nigel Cunningham
2006-04-26 16:22 ` Nick Piggin
2006-04-26 21:16 ` Rafael J. Wysocki
2006-04-26 8:10 ` Pavel Machek
2006-04-27 19:53 ` [RFC][PATCH] swsusp: support creating bigger images (rev. 2) Rafael J. Wysocki
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20060424221632.GQ3386@elf.ucw.cz \
--to=pavel@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-pm@osdl.org \
--cc=nigel@suspend2.net \
--cc=rjw@sisk.pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox