2005-03-04 10:19:42

by Pavel Machek

[permalink] [raw]
Subject: swsusp: allow resume from initramfs

Hi!

From: [email protected]

When using a fully modularized kernel it is necessary to activate
resume manually as the device node might not be available during
kernel init.

This patch implements a new sysfs attribute '/sys/power/resume' which
allows for manual activation of software resume. When read from it
prints the configured resume device in 'major:minor' format. When
written to it expects a device in 'major:minor' format. This device
is then checked for a suspended image and resume is started if a valid
image is found. The original functionality is left in place.

It should be used very carefully. I'll submit docs what that means;
usage from initramfs should be okay.

Signed-off-by: Hannes Reinecke <[email protected]>
Signed-off-by: Pavel Machek <[email protected]>

Please apply,
Pavel

--- linux.middle//include/linux/suspend.h 2005-02-14 14:14:21.000000000 +0100
+++ linux/include/linux/suspend.h 2005-03-03 13:23:17.000000000 +0100
@@ -35,6 +35,8 @@


#define SUSPEND_PD_PAGES(x) (((x)*sizeof(struct pbe))/PAGE_SIZE+1)
+
+extern dev_t swsusp_resume_device;

/* mm/vmscan.c */
extern int shrink_mem(void);
--- linux.middle//init/do_mounts.c 2005-02-03 22:28:15.000000000 +0100
+++ linux/init/do_mounts.c 2005-03-03 13:23:17.000000000 +0100
@@ -53,7 +53,7 @@
__setup("ro", readonly);
__setup("rw", readwrite);

-static dev_t __init try_name(char *name, int part)
+static dev_t try_name(char *name, int part)
{
char path[64];
char buf[32];
@@ -135,7 +135,7 @@
* is mounted on rootfs /sys.
*/

-dev_t __init name_to_dev_t(char *name)
+dev_t name_to_dev_t(char *name)
{
char s[32];
char *p;
--- linux.middle//kernel/power/disk.c 2005-03-02 00:22:49.000000000 +0100
+++ linux/kernel/power/disk.c 2005-03-04 10:15:46.000000000 +0100
@@ -16,7 +18,6 @@
#include <linux/device.h>
#include <linux/delay.h>
#include <linux/fs.h>
-#include <linux/device.h>
#include "power.h"


@@ -25,13 +26,16 @@

extern int swsusp_suspend(void);
extern int swsusp_write(void);
+extern int swsusp_check(void);
extern int swsusp_read(void);
+extern void swsusp_close(void);
extern int swsusp_resume(void);
extern int swsusp_free(void);


static int noresume = 0;
char resume_file[256] = CONFIG_PM_STD_PARTITION;
+dev_t swsusp_resume_device;

/**
* power_down - Shut machine down for hibernate.
@@ -123,45 +127,54 @@
}


-static int prepare(void)
+static int prepare_processes(void)
{
int error;

pm_prepare_console();

sys_sync();
+
if (freeze_processes()) {
error = -EBUSY;
- goto Thaw;
+ return error;
}

if (pm_disk_mode == PM_DISK_PLATFORM) {
if (pm_ops && pm_ops->prepare) {
if ((error = pm_ops->prepare(PM_SUSPEND_DISK)))
- goto Thaw;
+ return error;
}
}

/* Free memory before shutting down devices. */
free_some_memory();

+ return 0;
+}
+
+static void unprepare_processes(void)
+{
+ enable_nonboot_cpus();
+ thaw_processes();
+ pm_restore_console();
+}
+
+static int prepare_devices(void)
+{
+ int error;
+
disable_nonboot_cpus();
if ((error = device_suspend(PMSG_FREEZE))) {
printk("Some devices failed to suspend\n");
- goto Finish;
+ platform_finish();
+ enable_nonboot_cpus();
+ return error;
}

return 0;
- Finish:
- platform_finish();
- Thaw:
- enable_nonboot_cpus();
- thaw_processes();
- pm_restore_console();
- return error;
}

-
/**
* pm_suspend_disk - The granpappy of power management.
*
@@ -175,8 +188,15 @@
{
int error;

- if ((error = prepare()))
+ error = prepare_processes();
+ if (!error) {
+ error = prepare_devices();
+ }
+
+ if (error) {
+ unprepare_processes();
return error;
+ }

pr_debug("PM: Attempting to suspend to disk.\n");
if (pm_disk_mode == PM_DISK_FIRMWARE)
@@ -225,14 +245,26 @@
return 0;
}

+ pr_debug("PM: Checking swsusp image.\n");
+
+ if ((error = swsusp_check()))
+ goto Done;
+
+ pr_debug("PM: Preparing processes for restore.\n");
+
+ if ((error = prepare_processes())) {
+ swsusp_close();
+ goto Cleanup;
+ }
+
pr_debug("PM: Reading swsusp image.\n");

if ((error = swsusp_read()))
- goto Done;
+ goto Cleanup;

- pr_debug("PM: Preparing system for restore.\n");
+ pr_debug("PM: Preparing devices for restore.\n");

- if ((error = prepare()))
+ if ((error = prepare_devices()))
goto Free;

barrier();
@@ -244,6 +276,8 @@
finish();
Free:
swsusp_free();
+ Cleanup:
+ unprepare_processes();
Done:
pr_debug("PM: Resume from disk failed.\n");
return 0;
@@ -331,8 +365,41 @@

power_attr(disk);

+static ssize_t resume_show(struct subsystem * subsys, char *buf)
+{
+ return sprintf(buf,"%d:%d\n", MAJOR(swsusp_resume_device),
+ MINOR(swsusp_resume_device));
+}
+
+static ssize_t resume_store(struct subsystem * subsys, const char * buf, size_t n)
+{
+ int len;
+ char *p;
+ unsigned int maj, min;
+ int error = -EINVAL;
+ dev_t res;
+
+ p = memchr(buf, '\n', n);
+ len = p ? p - buf : n;
+
+ if (sscanf(buf, "%u:%u", &maj, &min) == 2) {
+ res = MKDEV(maj,min);
+ if (maj == MAJOR(res) && min == MINOR(res)) {
+ swsusp_resume_device = res;
+ printk("Attempting manual resume\n");
+ noresume = 0;
+ software_resume();
+ }
+ }
+
+ return error >= 0 ? n : error;
+}
+
+power_attr(resume);
+
static struct attribute * g[] = {
&disk_attr.attr,
+ &resume_attr.attr,
NULL,
};

--- linux.middle//kernel/power/swsusp.c 2005-02-28 21:29:06.000000000 +0100
+++ linux/kernel/power/swsusp.c 2005-03-03 13:35:52.000000000 +0100
@@ -79,7 +79,7 @@
static int nr_copy_pages_check;

extern char resume_file[];
-static dev_t resume_device;
+
/* Local variables that should not be affected by save */
unsigned int nr_copy_pages __nosavedata = 0;

@@ -169,7 +169,7 @@
struct inode *inode = file->f_dentry->d_inode;

return S_ISBLK(inode->i_mode) &&
- resume_device == MKDEV(imajor(inode), iminor(inode));
+ swsusp_resume_device == MKDEV(imajor(inode), iminor(inode));
}

static int swsusp_swap_check(void) /* This is called before saving image */
@@ -942,7 +942,7 @@
/*
* Returns true if given address/order collides with any orig_address
*/
-static int __init does_collide_order(unsigned long addr, int order)
+static int does_collide_order(unsigned long addr, int order)
{
int i;

@@ -975,7 +975,7 @@
*eaten_memory = c;
}

-static unsigned long __init get_usable_page(unsigned gfp_mask)
+static unsigned long get_usable_page(unsigned gfp_mask)
{
unsigned long m;

@@ -989,7 +989,7 @@
return m;
}

-static void __init free_eaten_memory(void)
+static void free_eaten_memory(void)
{
unsigned long m;
void **c;
@@ -1012,7 +1012,7 @@
* pages later
*/

-static int __init check_pagedir(struct pbe *pblist)
+static int check_pagedir(struct pbe *pblist)
{
struct pbe *p;

@@ -1036,7 +1036,7 @@
* restore from the loaded pages later. We relocate them here.
*/

-static struct pbe * __init swsusp_pagedir_relocate(struct pbe *pblist)
+static struct pbe * swsusp_pagedir_relocate(struct pbe *pblist)
{
struct zone *zone;
unsigned long zone_pfn;
@@ -1185,7 +1185,7 @@
* I really don't think that it's foolproof but more than nothing..
*/

-static const char * __init sanity_check(void)
+static const char * sanity_check(void)
{
dump_info();
if(swsusp_info.version_code != LINUX_VERSION_CODE)
@@ -1206,7 +1206,7 @@
}


-static int __init check_header(void)
+static int check_header(void)
{
const char * reason = NULL;
int error;
@@ -1224,7 +1224,7 @@
return error;
}

-static int __init check_sig(void)
+static int check_sig(void)
{
int error;

@@ -1254,7 +1254,7 @@
* already did that.
*/

-static int __init data_read(struct pbe *pblist)
+static int data_read(struct pbe *pblist)
{
struct pbe * p;
int error = 0;
@@ -1282,13 +1282,13 @@
return error;
}

-extern dev_t __init name_to_dev_t(const char *line);
+extern dev_t name_to_dev_t(const char *line);

/**
* read_pagedir - Read page backup list pages from swap
*/

-static int __init read_pagedir(struct pbe *pblist)
+static int read_pagedir(struct pbe *pblist)
{
struct pbe *pbpage, *p;
unsigned i = 0;
@@ -1322,10 +1322,9 @@
}


-static int __init read_suspend_image(void)
+static int check_suspend_image(void)
{
int error = 0;
- struct pbe *p;

if ((error = check_sig()))
return error;
@@ -1333,6 +1332,14 @@
if ((error = check_header()))
return error;

+ return 0;
+}
+
+static int read_suspend_image(void)
+{
+ int error = 0;
+ struct pbe *p;
+
if (!(p = alloc_pagedir(nr_copy_pages)))
return -ENOMEM;

@@ -1363,30 +1370,72 @@
}

/**
- * swsusp_read - Read saved image from swap.
+ * swsusp_check - Check for saved image in swap
*/

-int __init swsusp_read(void)
+int swsusp_check(void)
{
int error;

- if (!strlen(resume_file))
- return -ENOENT;
-
- resume_device = name_to_dev_t(resume_file);
- pr_debug("swsusp: Resume From Partition: %s\n", resume_file);
+ if (!swsusp_resume_device) {
+ if (!strlen(resume_file))
+ return -ENOENT;
+ swsusp_resume_device = name_to_dev_t(resume_file);
+ pr_debug("swsusp: Resume From Partition %s\n", resume_file);
+ } else {
+ pr_debug("swsusp: Resume From Partition %d:%d\n",
+ MAJOR(swsusp_resume_device), MINOR(swsusp_resume_device));
+ }

- resume_bdev = open_by_devnum(resume_device, FMODE_READ);
+ resume_bdev = open_by_devnum(swsusp_resume_device, FMODE_READ);
if (!IS_ERR(resume_bdev)) {
set_blocksize(resume_bdev, PAGE_SIZE);
- error = read_suspend_image();
- blkdev_put(resume_bdev);
+ error = check_suspend_image();
+ if (error)
+ blkdev_put(resume_bdev);
} else
error = PTR_ERR(resume_bdev);

if (!error)
- pr_debug("Reading resume file was successful\n");
+ pr_debug("swsusp: resume file found\n");
+ else
+ pr_debug("swsusp: Error %d check for resume file\n", error);
+ return error;
+}
+
+/**
+ * swsusp_read - Read saved image from swap.
+ */
+
+int swsusp_read(void)
+{
+ int error;
+
+ if (IS_ERR(resume_bdev)) {
+ pr_debug("swsusp: block device not initialised\n");
+ return PTR_ERR(resume_bdev);
+ }
+
+ error = read_suspend_image();
+ blkdev_put(resume_bdev);
+
+ if (!error)
+ pr_debug("swsusp: Reading resume file was successful\n");
else
pr_debug("swsusp: Error %d resuming\n", error);
return error;
}
+
+/**
+ * swsusp_close - close swap device.
+ */
+
+void swsusp_close(void)
+{
+ if (IS_ERR(resume_bdev)) {
+ pr_debug("swsusp: block device not initialised\n");
+ return;
+ }
+
+ blkdev_put(resume_bdev);
+}

--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!


2005-03-04 11:15:42

by Andrew Morton

[permalink] [raw]
Subject: Re: swsusp: allow resume from initramfs

Pavel Machek <[email protected]> wrote:
>
> When using a fully modularized kernel it is necessary to activate
> resume manually as the device node might not be available during
> kernel init.

I don't understand how this can be affected by the modularness of the
kernel. Can you explain a little more?

Would it not be simpler to just add "resume=03:02" to the boot command line?

2005-03-04 11:21:30

by Pavel Machek

[permalink] [raw]
Subject: Re: swsusp: allow resume from initramfs

On P? 04-03-05 03:04:10, Andrew Morton wrote:
> Pavel Machek <[email protected]> wrote:
> >
> > When using a fully modularized kernel it is necessary to activate
> > resume manually as the device node might not be available during
> > kernel init.
>
> I don't understand how this can be affected by the modularness of the
> kernel. Can you explain a little more?
>
> Would it not be simpler to just add "resume=03:02" to the boot
> command line?

Problem is if 03:02 is IDE module, and you don't have it built into
kernel. Then you want to insmod it from initramfs, and only then
activate resume.

For some reasons (probably good ones) distributions insists on having
everything as modules. At least SuSE and Debian want this... It also
allows stuff like graphically asking "you booted wrong kernel, do you
want me to wipe the signature, or will you reboot the correct kernel",
because you can do it userspace in initrd before actually calling
resume.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

2005-03-04 13:35:54

by Bodo Eggert

[permalink] [raw]
Subject: Re: swsusp: allow resume from initramfs

Andrew Morton <[email protected]> wrote:

> Would it not be simpler to just add "resume=03:02" to the boot command line?

Some devices have random device numbers.

2005-03-04 17:20:56

by Stefan Seyfried

[permalink] [raw]
Subject: Re: swsusp: allow resume from initramfs

Andrew Morton wrote:

> I don't understand how this can be affected by the modularness of the
> kernel. Can you explain a little more?

normally, resume takes place _before_ the initramfs is entered. If your
swap device depends on a module that is loaded from initramfs, you are lost.

This patch (or the version in the kernel i am running right now at
least) still does this (resume early), but if it does not find a device,
it allows resume to be triggered from initramfs after the module is loaded.

Excerpt from dmesg on my machine (i did boot and not resume this time):
[...]
TCP established hash table entries: 32768 (order: 6, 262144 bytes)
TCP bind hash table entries: 32768 (order: 5, 131072 bytes)
TCP: Hash tables configured (established 32768 bind 32768)
NET: Registered protocol family 1
PM: Checking swsusp image.
PM: Resume from disk failed.
ACPI wakeup devices:
LID PBTN PCI0 USB0 USB1 USB2 USB3 MODM PCIE
ACPI: (supports S0 S1 S3 S4 S4bios S5)
Freeing unused kernel memory: 204k freed
input: AT Translated Set 2 keyboard on isa0060/serio0
input: PS/2 Generic Mouse on isa0060/serio1
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH4: IDE controller at PCI slot 0000:00:1f.1
PCI: Enabling device 0000:00:1f.1 (0005 -> 0007)
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI interrupt 0000:00:1f.1[A] -> GSI 11 (level, low) -> IRQ 11
ICH4: chipset revision 1
ICH4: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0xbfa0-0xbfa7, BIOS settings: hda:DMA, hdb:pio
ide1: BM-DMA at 0xbfa8-0xbfaf, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: IC25N060ATMR04-0, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: HL-DT-STCD-RW/DVD-ROM GCC-4243N, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 1024KiB
hda: 117210240 sectors (60011 MB) w/7884KiB Cache, CHS=16383/255/63,
UDMA(100)
hda: cache flushes supported
hda: hda1 hda2 hda3 hda4 < hda5 hda6 >
ide-floppy driver 0.99.newide
hdc: ATAPI 24X DVD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
Attempting manual resume
PM: Checking swsusp image.
swsusp: Suspend partition has wrong signature?
PM: Resume from disk failed.
ReiserFS: hda3: found reiserfs format "3.6" with standard journal
ReiserFS: hda3: using ordered data mode

unfortunately the errors did not get caught by dmesg, but the first
error is -6 (no such device), later it is -22 (-EINVAL, no valid suspend
signature). This is in fact ok since i did not suspend before ;-)

Hope this helps (and the patch is working fine in my extended tests, it
could get some documentation on how to set it up since it is not totally
trivial. Hannes?).

Stefan

2005-03-04 17:50:51

by Barry K. Nathan

[permalink] [raw]
Subject: Re: swsusp: allow resume from initramfs

On Fri, Mar 04, 2005 at 03:04:10AM -0800, Andrew Morton wrote:
> I don't understand how this can be affected by the modularness of the
> kernel. Can you explain a little more?
>
> Would it not be simpler to just add "resume=03:02" to the boot command line?

In addition to what others have mentioned, there's also the situation
where swap is on a logical volume. In that case, the initramfs needs to
get LVM up and running before you can even think about resuming.

Swap on a logical volume is the default Fedora Core 3 partition layout,
and I imagine it's the default for Red Hat Enterprise Linux 4 as well.

-Barry K. Nathan <[email protected]>

2005-03-04 23:52:37

by Nigel Cunningham

[permalink] [raw]
Subject: Re: swsusp: allow resume from initramfs

Hi.

On Sat, 2005-03-05 at 09:07, Pavel Machek wrote:
> Hi!
>
> > > > You guys are reinventing the wheel a lot at the moment and I'm in the
> > > > middle of doing it for x86_64 lowlevel code :> Can we see if we can work
> > > > a little more closely - perhaps we can get some shared code going that
> > > > will allow us to handle these issues without stepping on each others'
> > > > feet? In particular, shared code for
> > > >
> > > > - initramfs and initrd support
> > >
> > > Its actually done, and it was few strategically placed lines of code
> > > (like 20 lines). I do not think it can be meaningfully shared.
> >
> > Mmm. But if we're both putting hooks in the same places...
>
> There are very little hooks... But we may want to make sure we have
> same userland interface. swsusp uses "echo 3:5 > /sys/power/resume" to
> trigger resume from device major 3 minor 5.
>
> > > > - lowlevel suspend & resume
> > >
> > > This makes very good sense to share. We have i386, x86-64 and ppc
> > > versions. They simply walk list of pbe's; that should be simple enough
> > > to be usable for suspend2, too....
> >
> > The CPU save and restore, yes. But I use a different format for
> > recording the image metadata (I use bitmaps to record the locations of
> > pages). Perhaps I should hasten to mention the bitmaps are discontiguous
> > - single pages connected by a kmalloc'd list. The copyback itself will
> > need to stay distinct.
>
> Hmm, bitmaps? Okay, then low-level code needs to stay separate. (And
> thats bad, I wanted that one to be shared most).

Mmm. As you might remember, I used extents from 1.0 to save space. The
feedback from the last submission to LKML about getting rid of the
page_alloc.c hooks made me re-examine the use of the memory pool, which
made me re-examine the format in which the data was stored. Switching to
bitmaps meant that after saving the LRU pages, I can recalculate what
remains to be saved without ever changing the result in the process.
(Using extents, there was a small chance that the recalculated metadata
would require an extra extent on an extra page, which means you have to
recalculate everything again :<. With discontiguous bitmaps, I get
efficient storage, no need for > order zero allocations and no feedback
whatsoever when recalculating image metadata. Besides removing the
memory pool code, I've already removed some more, and am about to
simplify the code for the remaining extents (for storage metadata). I
hope to also be able to further simplify the image preparation code too.

All that to say "Bitmaps were a definite win!". Perhaps I can sell you
on the advantages of using them :>

By the way, did you see the effect of the memory eating patch? I didn't
think about it until someone emailed me, but the improvement was 50x
speed in the best case!

Nigel
--
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://softwaresuspend.berlios.de


2005-03-05 00:07:24

by Pavel Machek

[permalink] [raw]
Subject: Re: swsusp: allow resume from initramfs

Hi!

> > Hmm, bitmaps? Okay, then low-level code needs to stay separate. (And
> > thats bad, I wanted that one to be shared most).
>
> Mmm. As you might remember, I used extents from 1.0 to save space. The
> feedback from the last submission to LKML about getting rid of the
> page_alloc.c hooks made me re-examine the use of the memory pool, which
> made me re-examine the format in which the data was stored. Switching to
> bitmaps meant that after saving the LRU pages, I can recalculate what
> remains to be saved without ever changing the result in the process.
> (Using extents, there was a small chance that the recalculated metadata
> would require an extra extent on an extra page, which means you have to
> recalculate everything again :<. With discontiguous bitmaps, I get
> efficient storage, no need for > order zero allocations and no feedback
> whatsoever when recalculating image metadata. Besides removing the
> memory pool code, I've already removed some more, and am about to
> simplify the code for the remaining extents (for storage metadata). I
> hope to also be able to further simplify the image preparation code too.
>
> All that to say "Bitmaps were a definite win!". Perhaps I can sell you
> on the advantages of using them :>

Not sure, if one bit goes wrong you put everything in the wrong places
:-). Linklist seems just okay to me, no > 4K allocations. I'm not sure
why recalculation is that big problem.

> By the way, did you see the effect of the memory eating patch? I didn't
> think about it until someone emailed me, but the improvement was 50x
> speed in the best case!

Well, more interesting was that you actually freed much more memory
with your patch. *You actually made memory freeing to work*. So yes, I
like that one.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

2005-03-05 01:19:27

by Nigel Cunningham

[permalink] [raw]
Subject: Re: swsusp: allow resume from initramfs

Hi.

On Sat, 2005-03-05 at 09:55, Pavel Machek wrote:
> > All that to say "Bitmaps were a definite win!". Perhaps I can sell you
> > on the advantages of using them :>
>
> Not sure, if one bit goes wrong you put everything in the wrong places
> :-). Linklist seems just okay to me, no > 4K allocations. I'm not sure
> why recalculation is that big problem.

So you make sure all the bits are right :> I can understand you being
happy with linked lists; it's just that they're really inefficient
spacewise. Since you're freeing far more memory at the moment, it's not
an issue.

Regarding recalculation being a problem, I want Suspend to always work.
If you have unpredictable variation, you have a potential source of
failure.

> > By the way, did you see the effect of the memory eating patch? I didn't
> > think about it until someone emailed me, but the improvement was 50x
> > speed in the best case!
>
> Well, more interesting was that you actually freed much more memory
> with your patch. *You actually made memory freeing to work*. So yes, I
> like that one.

You might be misreading me. When you set the image size limit setting in
Suspend2, it's a soft limit. The image size wouldn't actually get down
to 2 meg; Suspend would just aim for that and eat memory until it saw it
wasn't getting anywhere.

Regards,

Nigel
--
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://softwaresuspend.berlios.de


2005-03-05 00:37:03

by Pavel Machek

[permalink] [raw]
Subject: Re: swsusp: allow resume from initramfs

Hi!

> > > You guys are reinventing the wheel a lot at the moment and I'm in the
> > > middle of doing it for x86_64 lowlevel code :> Can we see if we can work
> > > a little more closely - perhaps we can get some shared code going that
> > > will allow us to handle these issues without stepping on each others'
> > > feet? In particular, shared code for
> > >
> > > - initramfs and initrd support
> >
> > Its actually done, and it was few strategically placed lines of code
> > (like 20 lines). I do not think it can be meaningfully shared.
>
> Mmm. But if we're both putting hooks in the same places...

There are very little hooks... But we may want to make sure we have
same userland interface. swsusp uses "echo 3:5 > /sys/power/resume" to
trigger resume from device major 3 minor 5.

> > > - lowlevel suspend & resume
> >
> > This makes very good sense to share. We have i386, x86-64 and ppc
> > versions. They simply walk list of pbe's; that should be simple enough
> > to be usable for suspend2, too....
>
> The CPU save and restore, yes. But I use a different format for
> recording the image metadata (I use bitmaps to record the locations of
> pages). Perhaps I should hasten to mention the bitmaps are discontiguous
> - single pages connected by a kmalloc'd list. The copyback itself will
> need to stay distinct.

Hmm, bitmaps? Okay, then low-level code needs to stay separate. (And
thats bad, I wanted that one to be shared most).
Pavel

--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

2005-03-04 23:43:17

by Nigel Cunningham

[permalink] [raw]
Subject: Re: swsusp: allow resume from initramfs

Hi Pavel et al.

On Sat, 2005-03-05 at 04:50, Barry K. Nathan wrote:
> On Fri, Mar 04, 2005 at 03:04:10AM -0800, Andrew Morton wrote:
> > I don't understand how this can be affected by the modularness of the
> > kernel. Can you explain a little more?
> >
> > Would it not be simpler to just add "resume=03:02" to the boot command line?
>
> In addition to what others have mentioned, there's also the situation
> where swap is on a logical volume. In that case, the initramfs needs to
> get LVM up and running before you can even think about resuming.
>
> Swap on a logical volume is the default Fedora Core 3 partition layout,
> and I imagine it's the default for Red Hat Enterprise Linux 4 as well.

You guys are reinventing the wheel a lot at the moment and I'm in the
middle of doing it for x86_64 lowlevel code :> Can we see if we can work
a little more closely - perhaps we can get some shared code going that
will allow us to handle these issues without stepping on each others'
feet? In particular, shared code for

- initramfs and initrd support
- lowlevel suspend & resume

would be good, wouldn't it?

I'm tempted to add setting and checking signatures, but I'm also in the
middle of implementing support for writing the image to a file, so that
could get messy.

Regards,

Nigel
--
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://suspend2.net


2005-03-04 23:43:32

by Pavel Machek

[permalink] [raw]
Subject: Re: swsusp: allow resume from initramfs

Hi!

> > > I don't understand how this can be affected by the modularness of the
> > > kernel. Can you explain a little more?
> > >
> > > Would it not be simpler to just add "resume=03:02" to the boot command line?
> >
> > In addition to what others have mentioned, there's also the situation
> > where swap is on a logical volume. In that case, the initramfs needs to
> > get LVM up and running before you can even think about resuming.
> >
> > Swap on a logical volume is the default Fedora Core 3 partition layout,
> > and I imagine it's the default for Red Hat Enterprise Linux 4 as well.
>
> You guys are reinventing the wheel a lot at the moment and I'm in the
> middle of doing it for x86_64 lowlevel code :> Can we see if we can work
> a little more closely - perhaps we can get some shared code going that
> will allow us to handle these issues without stepping on each others'
> feet? In particular, shared code for
>
> - initramfs and initrd support

Its actually done, and it was few strategically placed lines of code
(like 20 lines). I do not think it can be meaningfully shared.

> - lowlevel suspend & resume

This makes very good sense to share. We have i386, x86-64 and ppc
versions. They simply walk list of pbe's; that should be simple enough
to be usable for suspend2, too....
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

2005-03-04 23:43:26

by Nigel Cunningham

[permalink] [raw]
Subject: Re: swsusp: allow resume from initramfs

Hi.

On Sat, 2005-03-05 at 08:43, Pavel Machek wrote:
> > You guys are reinventing the wheel a lot at the moment and I'm in the
> > middle of doing it for x86_64 lowlevel code :> Can we see if we can work
> > a little more closely - perhaps we can get some shared code going that
> > will allow us to handle these issues without stepping on each others'
> > feet? In particular, shared code for
> >
> > - initramfs and initrd support
>
> Its actually done, and it was few strategically placed lines of code
> (like 20 lines). I do not think it can be meaningfully shared.

Mmm. But if we're both putting hooks in the same places...

> > - lowlevel suspend & resume
>
> This makes very good sense to share. We have i386, x86-64 and ppc
> versions. They simply walk list of pbe's; that should be simple enough
> to be usable for suspend2, too....

The CPU save and restore, yes. But I use a different format for
recording the image metadata (I use bitmaps to record the locations of
pages). Perhaps I should hasten to mention the bitmaps are discontiguous
- single pages connected by a kmalloc'd list. The copyback itself will
need to stay distinct.

Regards,

Nigel
--
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Bus: +61 (2) 6291 9554; Hme: +61 (2) 6292 8028; Mob: +61 (417) 100 574

Maintainer of Suspend2 Kernel Patches http://softwaresuspend.berlios.de


2005-03-05 21:58:21

by Pavel Machek

[permalink] [raw]
Subject: swsusp memory freeing [was Re: swsusp: allow resume from initramfs]

Hi!

> > > By the way, did you see the effect of the memory eating patch? I didn't
> > > think about it until someone emailed me, but the improvement was 50x
> > > speed in the best case!
> >
> > Well, more interesting was that you actually freed much more memory
> > with your patch. *You actually made memory freeing to work*. So yes, I
> > like that one.
>
> You might be misreading me. When you set the image size limit setting in
> Suspend2, it's a soft limit. The image size wouldn't actually get down
> to 2 meg; Suspend would just aim for that and eat memory until it saw it
> wasn't getting anywhere.

Well, numbers looked like with same 2MB soft limit, "new" version
actually freed more memory. Perhaps that's not the case...
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

2005-03-06 22:24:16

by Andreas Jellinghaus

[permalink] [raw]
Subject: Re: swsusp: allow resume from initramfs

Great, with this patch I can setup an encrypted swap partition,
and resume from it (after the initramfs asked for the password
and set up the dm-crypt table).

But wait, I'm using swapfiles. swap is fine with files.
what about swsuspend? and if it works with files, too,
what about this resume interface?

Andreas

2005-03-06 22:30:20

by Andreas Jellinghaus

[permalink] [raw]
Subject: Re: swsusp: allow resume from initramfs

On Fri, 04 Mar 2005 11:35:12 +0000, Andrew Morton wrote:
> I don't understand how this can be affected by the modularness of the
> kernel. Can you explain a little more?
>
> Would it not be simpler to just add "resume=03:02" to the boot command line?

initramfs can also be used to ask for a passphrase, hash it, and setup
some (de)cryption dm tables.

Andreas

2005-03-07 15:12:45

by Pavel Machek

[permalink] [raw]
Subject: Re: swsusp: allow resume from initramfs

Hi!

> Great, with this patch I can setup an encrypted swap partition,
> and resume from it (after the initramfs asked for the password
> and set up the dm-crypt table).
>
> But wait, I'm using swapfiles. swap is fine with files.
> what about swsuspend? and if it works with files, too,
> what about this resume interface?

swsusp needs device.

Pavel

--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!