* Re: Remove pmdisk from kernel
2004-03-15 21:21 ` Andrew Morton
@ 2004-03-15 19:38 ` Nigel Cunningham
2004-03-15 21:53 ` Andrew Morton
2004-03-16 0:56 ` Pavel Machek
0 siblings, 2 replies; 14+ messages in thread
From: Nigel Cunningham @ 2004-03-15 19:38 UTC (permalink / raw)
To: Andrew Morton; +Cc: Pavel Machek, Linux Kernel Mailing List, Patrick Mochel
Most of those changes are hooks to make the freezer for more reliable.
That part of the functionality could be isolated from the bulk of
suspend2. Would that make you happy?
Nigel
On Tue, 2004-03-16 at 10:21, Andrew Morton wrote:
> Pavel Machek <pavel@ucw.cz> wrote:
> >
> > > It would be unfortunate if Pat had more development planned or even
> > > underway. Have we checked?
> >
> > Last time I attempted pmdisk removal, he did not react. Lets try one
> > more time.
>
> OK. Best use his current email address..
>
> > I believe that you don't want swsusp2 in 2.6. It has hooks all over
> > the place:
> > ...
> > 109 files changed, 3254 insertions(+), 624 deletions(-)
>
> Ahem. Agreed.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Nigel Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6253 0250 (home)
Evolution (n): A hypothetical process whereby infinitely improbable events occur
with alarming frequency, order arises from chaos, and no one is given credit.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Remove pmdisk from kernel
@ 2004-03-15 19:54 Pavel Machek
2004-03-15 20:53 ` Andrew Morton
0 siblings, 1 reply; 14+ messages in thread
From: Pavel Machek @ 2004-03-15 19:54 UTC (permalink / raw)
To: Andrew Morton, kernel list
Hi!
This removes pmdisk from kernel. Nobody maintains it and swsusp
provides same functionality (and more, pmdisk is actually fork of
swsusp code).
3 files need to be removed by hand, I did not want to obscure patch by
removing them like that (and you probably have slightly different
pmdisk.c, anyway).
rm arch/i386/power/pmdisk.S
rm kernel/power/disk.c
rm kernel/power/pmdisk.c
Pavel
PS: Alternatively, I'm wiling to kill swsusp, rename pmdisk to "swap
suspend", and submit patches to fix it. Its going to be slightly more
complicated, through...
--- linux/arch/i386/defconfig 2004-03-11 18:16:02.000000000 +0100
+++ linux-nopmdisk/arch/i386/defconfig 2004-03-15 20:15:35.000000000 +0100
@@ -117,7 +117,6 @@
#
CONFIG_PM=y
CONFIG_SOFTWARE_SUSPEND=y
-# CONFIG_PM_DISK is not set
#
# ACPI (Advanced Configuration and Power Interface) Support
--- linux/arch/i386/power/Makefile 2003-09-28 22:05:30.000000000 +0200
+++ linux-nopmdisk/arch/i386/power/Makefile 2004-03-15 20:15:54.000000000 +0100
@@ -1,3 +1,2 @@
obj-$(CONFIG_PM) += cpu.o
-obj-$(CONFIG_PM_DISK) += pmdisk.o
obj-$(CONFIG_SOFTWARE_SUSPEND) += swsusp.o
--- linux/kernel/power/Kconfig 2004-02-23 20:20:42.000000000 +0100
+++ linux-nopmdisk/kernel/power/Kconfig 2004-03-15 20:11:56.000000000 +0100
@@ -42,52 +42,3 @@
For more information take a look at Documentation/power/swsusp.txt.
-config PM_DISK
- bool "Suspend-to-Disk Support"
- depends on PM && SWAP
- ---help---
- Suspend-to-disk is a power management state in which the contents
- of memory are stored on disk and the entire system is shut down or
- put into a low-power state (e.g. ACPI S4). When the computer is
- turned back on, the stored image is loaded from disk and execution
- resumes from where it left off before suspending.
-
- This config option enables the core infrastructure necessary to
- perform the suspend and resume transition.
-
- Currently, this suspend-to-disk implementation is based on a forked
- version of the swsusp code base. As such, it's still experimental,
- and still relies on CONFIG_SWAP.
-
- More information can be found in Documentation/power/.
-
- If unsure, Say N.
-
-config PM_DISK_PARTITION
- string "Default resume partition"
- depends on PM_DISK
- default ""
- ---help---
- The default resume partition is the partition that the pmdisk suspend-
- to-disk implementation will look for a suspended disk image.
-
- The partition specified here will be different for almost every user.
- It should be a valid swap partition (at least for now) that is turned
- on before suspending.
-
- The partition specified can be overridden by specifying:
-
- pmdisk=/dev/<other device>
-
- which will set the resume partition to the device specified.
-
- One may also do:
-
- pmdisk=off
-
- to inform the kernel not to perform a resume transition.
-
- Note there is currently not a way to specify which device to save the
- suspended image to. It will simply pick the first available swap
- device.
-
--- linux/kernel/power/Makefile 2003-09-28 22:06:44.000000000 +0200
+++ linux-nopmdisk/kernel/power/Makefile 2004-03-15 20:12:13.000000000 +0100
@@ -1,5 +1,4 @@
obj-y := main.o process.o console.o pm.o
obj-$(CONFIG_SOFTWARE_SUSPEND) += swsusp.o
-obj-$(CONFIG_PM_DISK) += disk.o pmdisk.o
obj-$(CONFIG_MAGIC_SYSRQ) += poweroff.o
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Remove pmdisk from kernel
2004-03-15 21:53 ` Andrew Morton
@ 2004-03-15 20:14 ` Nigel Cunningham
0 siblings, 0 replies; 14+ messages in thread
From: Nigel Cunningham @ 2004-03-15 20:14 UTC (permalink / raw)
To: Andrew Morton
Cc: Pavel Machek, Linux Kernel Mailing List, Patrick Mochel, Michael Frank
Hi.
On Tue, 2004-03-16 at 10:53, Andrew Morton wrote:
> Nigel Cunningham <ncunningham@users.sourceforge.net> wrote:
> >
> > On Tue, 2004-03-16 at 10:21, Andrew Morton wrote:
> > > Pavel Machek <pavel@ucw.cz> wrote:
> > > >
> > > > I believe that you don't want swsusp2 in 2.6. It has hooks all over
> > > > the place:
> > > > ...
> > > > 109 files changed, 3254 insertions(+), 624 deletions(-)
> > >
> > > Ahem. Agreed.
> >
> > Most of those changes are hooks to make the freezer for more reliable.
> > That part of the functionality could be isolated from the bulk of
> > suspend2. Would that make you happy?
>
> It would make us happier. Even happier would be a series of small, well
> explained patches which bring swsusp into a final shape upon which more
> than one developer actually agrees.
I'd love to do that too. Unfortunately I'm really busy with my new job,
so things have progressed far more slowly than I'd have liked. I'm also
not sure how to deal with some of the changes that just about completely
rewrite sections.
> These wholesale replacements and deletions are an indication that something
> has gone wrong with the development process here.
I spent a long time trying to get the freezer working reliably with the
kind of implementation Pavel uses. The problem I kept running into time
and again was that you can't know dependancies between processes when it
comes to signalling them; process A might happily be frozen, but then
process B can't be frozen becaue it is waiting on something process A
has (eg ls/nfsd). By tracking which processes are in those
'can't-be-frozen-here' sections, I have managed to make the freezer far
more reliable, even under high load. Michael Frank has done some extreme
stress testing and can verify this.
Nigel
--
Nigel Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6253 0250 (home)
Evolution (n): A hypothetical process whereby infinitely improbable events occur
with alarming frequency, order arises from chaos, and no one is given credit.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Remove pmdisk from kernel
2004-03-15 19:54 Remove pmdisk from kernel Pavel Machek
@ 2004-03-15 20:53 ` Andrew Morton
2004-03-15 20:57 ` Pavel Machek
0 siblings, 1 reply; 14+ messages in thread
From: Andrew Morton @ 2004-03-15 20:53 UTC (permalink / raw)
To: Pavel Machek; +Cc: linux-kernel
Pavel Machek <pavel@ucw.cz> wrote:
>
> This removes pmdisk from kernel.
It would be unfortunate if Pat had more development planned or even
underway. Have we checked?
> PS: Alternatively, I'm wiling to kill swsusp, rename pmdisk to "swap
> suspend", and submit patches to fix it. Its going to be slightly more
> complicated, through...
People have suggested that I incorporate swsusp2. Where does this fit into
things?
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Remove pmdisk from kernel
2004-03-15 20:53 ` Andrew Morton
@ 2004-03-15 20:57 ` Pavel Machek
2004-03-15 21:21 ` Andrew Morton
` (2 more replies)
0 siblings, 3 replies; 14+ messages in thread
From: Pavel Machek @ 2004-03-15 20:57 UTC (permalink / raw)
To: Andrew Morton, Patrick Mochel; +Cc: linux-kernel
Hi!
> Pavel Machek <pavel@ucw.cz> wrote:
> >
> > This removes pmdisk from kernel.
>
> It would be unfortunate if Pat had more development planned or even
> underway. Have we checked?
Last time I attempted pmdisk removal, he did not react. Lets try one
more time.
> > PS: Alternatively, I'm wiling to kill swsusp, rename pmdisk to "swap
> > suspend", and submit patches to fix it. Its going to be slightly more
> > complicated, through...
>
> People have suggested that I incorporate swsusp2. Where does this fit into
> things?
I believe that you don't want swsusp2 in 2.6. It has hooks all over
the place:
Pavel
Documentation/kernel-parameters.txt | 9
Documentation/power/swsusp2.txt | 495 +++++++++++++++++++++++++++++++
arch/arm/kernel/ecard.c | 6
arch/i386/kernel/apm.c | 8
arch/i386/kernel/process.c | 25 +
arch/i386/kernel/signal.c | 5
arch/i386/kernel/smp.c | 2
arch/i386/mm/pageattr.c | 2
arch/i386/power/Makefile | 1
arch/i386/power/cpu.c | 8
arch/i386/power/swsusp2-asm.S | 259 ++++++++++++++++
arch/i386/power/swsusp2.c | 130 ++++++++
arch/ppc/Kconfig | 2
arch/ppc/Makefile | 1
arch/ppc/kernel/signal.c | 6
arch/ppc/kernel/vmlinux.lds.S | 6
arch/ppc/power/Makefile | 2
arch/ppc/power/cpu.c | 72 ++++
arch/ppc/power/cpu_reg.S | 325 ++++++++++++++++++++
arch/ppc/power/swsusp2-asm.S | 51 +++
arch/ppc/power/swsusp2-copyback.S | 73 ++++
arch/ppc/power/swsusp2.c | 170 ++++++++++
drivers/acpi/sleep/proc.c | 7
drivers/block/loop.c | 3
drivers/char/hvc_console.c | 6
drivers/char/keyboard.c | 84 +++++
drivers/char/n_tty.c | 4
drivers/char/tty_io.c | 14
drivers/char/vt.c | 20 -
drivers/ide/ide-disk.c | 3
drivers/ieee1394/nodemgr.c | 12
drivers/input/serio/serio.c | 11
drivers/md/md.c | 3
drivers/media/video/msp3400.c | 14
drivers/media/video/tvaudio.c | 8
drivers/message/i2o/i2o_block.c | 11
drivers/message/i2o/i2o_core.c | 23 +
drivers/mtd/mtdblock.c | 4
drivers/net/8139too.c | 2
drivers/net/irda/sir_kthread.c | 10
drivers/net/wireless/airo.c | 2
drivers/parport/ieee1284.c | 4
drivers/pcmcia/cs.c | 11
drivers/scsi/scsi_error.c | 16 -
drivers/serial/8250.c | 100 ++++++
drivers/usb/core/hub.c | 10
drivers/usb/storage/usb.c | 14
fs/buffer.c | 89 ++++-
fs/dcache.c | 5
fs/devfs/base.c | 14
fs/exec.c | 18 +
fs/fcntl.c | 19 +
fs/jbd/journal.c | 20 -
fs/jffs/intrep.c | 15
fs/jffs2/background.c | 18 -
fs/jfs/jfs_logmgr.c | 24 -
fs/jfs/jfs_txnmgr.c | 61 ++-
fs/lockd/clntlock.c | 8
fs/lockd/clntproc.c | 6
fs/lockd/svc.c | 12
fs/locks.c | 8
fs/namei.c | 54 +++
fs/namespace.c | 16 -
fs/nfsd/nfssvc.c | 8
fs/open.c | 84 +++++
fs/pipe.c | 4
fs/proc/generic.c | 8
fs/proc/kmsg.c | 9
fs/read_write.c | 66 +++-
fs/stat.c | 41 ++
fs/super.c | 5
fs/sysfs/file.c | 4
fs/xfs/linux/xfs_buf.c | 11
fs/xfs/linux/xfs_super.c | 11
include/asm-i386/cpufeature.h | 1
include/asm-i386/mtrr.h | 4
include/asm-i386/tlbflush.h | 5
include/asm-ppc/suspend.h | 14
include/linux/pagemap.h | 5
include/linux/sched.h | 8
include/linux/selection.h | 4
include/linux/suspend-version-specific.h | 74 ++++
include/linux/suspend.h | 75 ----
include/linux/suspend1.h | 76 ++++
kernel/exit.c | 7
kernel/fork.c | 7
kernel/module.c | 27 +
kernel/panic.c | 5
kernel/power/Kconfig | 102 ++++++
kernel/power/Makefile | 12
kernel/power/console.c | 51 ---
kernel/power/disk.c | 3
kernel/power/main.c | 3
kernel/power/pmdisk.c | 2
kernel/power/process.c | 128 --------
kernel/power/swsusp.c | 2
kernel/sched.c | 10
kernel/softirq.c | 3
kernel/sys.c | 6
kernel/workqueue.c | 3
mm/page_alloc.c | 30 +
mm/pdflush.c | 8
mm/swapfile.c | 5
mm/vmscan.c | 443 ++++++++++++++++-----------
net/bluetooth/bnep/core.c | 11
net/bluetooth/rfcomm/core.c | 11
net/socket.c | 21 +
net/sunrpc/sched.c | 12
net/sunrpc/svcsock.c | 8
109 files changed, 3254 insertions(+), 624 deletions(-)
This is one small example what swsusp2 needs:
diff -ruN linux-2.6.2/fs/buffer.c software-suspend-linux-2.6.2/fs/buffer.c
--- linux-2.6.2/fs/buffer.c 2004-02-06 17:27:46.000000000 +1300
+++ software-suspend-linux-2.6.2/fs/buffer.c 2004-02-06 17:41:09.000000000 +1300
@@ -37,6 +37,7 @@
#include <linux/bio.h>
#include <linux/notifier.h>
#include <linux/cpu.h>
+#include <linux/init.h>
#include <asm/bitops.h>
static void invalidate_bh_lrus(void);
@@ -229,16 +230,24 @@
*/
int fsync_super(struct super_block *sb)
{
- sync_inodes_sb(sb, 0);
- DQUOT_SYNC(sb);
- lock_super(sb);
- if (sb->s_dirt && sb->s_op->write_super)
- sb->s_op->write_super(sb);
- unlock_super(sb);
- if (sb->s_op->sync_fs)
- sb->s_op->sync_fs(sb, 1);
- sync_blockdev(sb->s_bdev);
- sync_inodes_sb(sb, 1);
+#ifdef CONFIG_SOFTWARE_SUSPEND2
+ /* A safety net. During suspend, we might overwrite
+ * memory containing filesystem info. We don't then
+ * want to sync it to disk. */
+ if (likely(!(swsusp_state & FREEZE_UNREFRIGERATED)))
+#endif
+ {
+ sync_inodes_sb(sb, 0);
+ DQUOT_SYNC(sb);
+ lock_super(sb);
+ if (sb->s_dirt && sb->s_op->write_super)
+ sb->s_op->write_super(sb);
+ unlock_super(sb);
+ if (sb->s_op->sync_fs)
+ sb->s_op->sync_fs(sb, 1);
+ sync_blockdev(sb->s_bdev);
+ sync_inodes_sb(sb, 1);
+ }
return sync_blockdev(sb->s_bdev);
}
@@ -251,12 +260,20 @@
int fsync_bdev(struct block_device *bdev)
{
struct super_block *sb = get_super(bdev);
+ int result = 0;
+ DECLARE_SWSUSP_LOCAL_VAR;
+
+ SWSUSP_ACTIVITY_START(PF_SYNCTHREAD);
+ current->flags |= PF_SYNCTHREAD;
if (sb) {
int res = fsync_super(sb);
drop_super(sb);
return res;
}
- return sync_blockdev(bdev);
+ result = sync_blockdev(bdev);
+ current->flags &= ~PF_SYNCTHREAD;
+ SWSUSP_ACTIVITY_END;
+ return result;
}
/*
@@ -265,20 +282,34 @@
*/
static void do_sync(unsigned long wait)
{
- wakeup_bdflush(0);
- sync_inodes(0); /* All mappings, inodes and their blockdevs */
- DQUOT_SYNC(NULL);
- sync_supers(); /* Write the superblocks */
- sync_filesystems(0); /* Start syncing the filesystems */
- sync_filesystems(wait); /* Waitingly sync the filesystems */
- sync_inodes(wait); /* Mappings, inodes and blockdevs, again. */
- if (!wait)
- printk("Emergency Sync complete\n");
+#ifdef CONFIG_SOFTWARE_SUSPEND2
+ /* A safety net. During suspend, we might overwrite
+ * memory containing filesystem info. We don't then
+ * want to sync it to disk. */
+ if (likely(!(swsusp_state & FREEZE_UNREFRIGERATED)))
+#endif
+ {
+ wakeup_bdflush(0);
+ sync_inodes(0); /* All mappings, inodes and their blockdevs */
+ DQUOT_SYNC(NULL);
+ sync_supers(); /* Write the superblocks */
+ sync_filesystems(0); /* Start syncing the filesystems */
+ sync_filesystems(wait); /* Waitingly sync the filesystems */
+ sync_inodes(wait); /* Mappings, inodes and blockdevs, again. */
+ if (!wait)
+ printk("Emergency Sync complete\n");
+ }
}
asmlinkage long sys_sync(void)
{
+ DECLARE_SWSUSP_LOCAL_VAR;
+
+ SWSUSP_ACTIVITY_START(PF_SYNCTHREAD);
+ current->flags |= PF_SYNCTHREAD;
do_sync(1);
+ current->flags &= ~PF_SYNCTHREAD;
+ SWSUSP_ACTIVITY_END;
return 0;
}
@@ -319,6 +350,10 @@
struct file * file;
struct address_space *mapping;
int ret, err;
+ DECLARE_SWSUSP_LOCAL_VAR;
+
+ SWSUSP_ACTIVITY_START(PF_SYNCTHREAD);
+ current->flags |= PF_SYNCTHREAD;
ret = -EBADF;
file = fget(fd);
@@ -349,6 +384,8 @@
out_putf:
fput(file);
out:
+ current->flags &= ~PF_SYNCTHREAD;
+ SWSUSP_ACTIVITY_END;
return ret;
}
@@ -357,6 +394,10 @@
struct file * file;
struct address_space *mapping;
int ret, err;
+ DECLARE_SWSUSP_LOCAL_VAR;
+
+ SWSUSP_ACTIVITY_START(PF_SYNCTHREAD);
+ current->flags |= PF_SYNCTHREAD;
ret = -EBADF;
file = fget(fd);
@@ -384,6 +425,8 @@
out_putf:
fput(file);
out:
+ current->flags &= ~PF_SYNCTHREAD;
+ SWSUSP_ACTIVITY_END;
return ret;
}
@@ -1071,6 +1114,10 @@
* async buffer heads in use.
*/
free_more_memory();
+#ifdef CONFIG_SOFTWARE_SUSPEND2
+ if (suspend_task == current->pid)
+ cleanup_finished_swsusp_io();
+#endif
goto try_again;
}
@@ -2800,7 +2847,7 @@
*
* try_to_free_buffers() is non-blocking.
*/
-static inline int buffer_busy(struct buffer_head *bh)
+inline int buffer_busy(struct buffer_head *bh)
{
return atomic_read(&bh->b_count) |
(bh->b_state & ((1 << BH_Dirty) | (1 << BH_Lock)));
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Remove pmdisk from kernel
2004-03-15 20:57 ` Pavel Machek
@ 2004-03-15 21:21 ` Andrew Morton
2004-03-15 19:38 ` Nigel Cunningham
2004-03-16 1:32 ` Fedor Karpelevitch
[not found] ` <20040316091648.GB6301@pern.dea.icai.upco.es>
2 siblings, 1 reply; 14+ messages in thread
From: Andrew Morton @ 2004-03-15 21:21 UTC (permalink / raw)
To: Pavel Machek; +Cc: linux-kernel, Patrick Mochel
Pavel Machek <pavel@ucw.cz> wrote:
>
> > It would be unfortunate if Pat had more development planned or even
> > underway. Have we checked?
>
> Last time I attempted pmdisk removal, he did not react. Lets try one
> more time.
OK. Best use his current email address..
> I believe that you don't want swsusp2 in 2.6. It has hooks all over
> the place:
> ...
> 109 files changed, 3254 insertions(+), 624 deletions(-)
Ahem. Agreed.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Remove pmdisk from kernel
2004-03-15 19:38 ` Nigel Cunningham
@ 2004-03-15 21:53 ` Andrew Morton
2004-03-15 20:14 ` Nigel Cunningham
2004-03-16 0:56 ` Pavel Machek
1 sibling, 1 reply; 14+ messages in thread
From: Andrew Morton @ 2004-03-15 21:53 UTC (permalink / raw)
To: ncunningham; +Cc: pavel, linux-kernel, mochel
Nigel Cunningham <ncunningham@users.sourceforge.net> wrote:
>
> On Tue, 2004-03-16 at 10:21, Andrew Morton wrote:
> > Pavel Machek <pavel@ucw.cz> wrote:
> > >
> > > I believe that you don't want swsusp2 in 2.6. It has hooks all over
> > > the place:
> > > ...
> > > 109 files changed, 3254 insertions(+), 624 deletions(-)
> >
> > Ahem. Agreed.
>
> Most of those changes are hooks to make the freezer for more reliable.
> That part of the functionality could be isolated from the bulk of
> suspend2. Would that make you happy?
It would make us happier. Even happier would be a series of small, well
explained patches which bring swsusp into a final shape upon which more
than one developer actually agrees.
These wholesale replacements and deletions are an indication that something
has gone wrong with the development process here.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Remove pmdisk from kernel
2004-03-16 0:56 ` Pavel Machek
@ 2004-03-15 23:27 ` Nigel Cunningham
2004-03-16 10:17 ` Pavel Machek
0 siblings, 1 reply; 14+ messages in thread
From: Nigel Cunningham @ 2004-03-15 23:27 UTC (permalink / raw)
To: Pavel Machek; +Cc: Andrew Morton, Linux Kernel Mailing List, Patrick Mochel
Hi.
On Tue, 2004-03-16 at 13:56, Pavel Machek wrote:
> Hi!
>
> > Most of those changes are hooks to make the freezer for more reliable.
> > That part of the functionality could be isolated from the bulk of
> > suspend2. Would that make you happy?
>
> Yes, that would be very good. It would make it easy to see actual
> changes..
>
> [I still do not understand why those hooks are neccessary... kill
> -SIGSTOP works, right?]
Not always. Take for example the case where you have an NFS mount and
happen to be doing an ls when the suspend cycle is started. If you
signal the NFSd threads before the ls thread, the NFS threads will
refrigerate okay, but the ls thread will fail to stop because it's
waiting for data from the nfsd threads.
The best way to test the reliability of the current freezer
implementation is to grab Michael's test patches. They can load the
system down with NFS access, kernel compiles, benchmarks and so on.
You'll quickly see the freezer fail. My implementation handles those
loads flawlessly, and where problems are found, they're easily fixed.
Regards,
Nigel
--
Nigel Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6253 0250 (home)
Evolution (n): A hypothetical process whereby infinitely improbable events occur
with alarming frequency, order arises from chaos, and no one is given credit.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Remove pmdisk from kernel
2004-03-15 19:38 ` Nigel Cunningham
2004-03-15 21:53 ` Andrew Morton
@ 2004-03-16 0:56 ` Pavel Machek
2004-03-15 23:27 ` Nigel Cunningham
1 sibling, 1 reply; 14+ messages in thread
From: Pavel Machek @ 2004-03-16 0:56 UTC (permalink / raw)
To: Nigel Cunningham; +Cc: Andrew Morton, Linux Kernel Mailing List, Patrick Mochel
Hi!
> Most of those changes are hooks to make the freezer for more reliable.
> That part of the functionality could be isolated from the bulk of
> suspend2. Would that make you happy?
Yes, that would be very good. It would make it easy to see actual
changes..
[I still do not understand why those hooks are neccessary... kill
-SIGSTOP works, right?]
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Remove pmdisk from kernel
2004-03-15 20:57 ` Pavel Machek
2004-03-15 21:21 ` Andrew Morton
@ 2004-03-16 1:32 ` Fedor Karpelevitch
[not found] ` <20040316091648.GB6301@pern.dea.icai.upco.es>
2 siblings, 0 replies; 14+ messages in thread
From: Fedor Karpelevitch @ 2004-03-16 1:32 UTC (permalink / raw)
To: linux-kernel; +Cc: Pavel Machek, Andrew Morton, Patrick Mochel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
15 March 2004 12:57, Pavel Machek wrote:
> > > PS: Alternatively, I'm wiling to kill swsusp, rename pmdisk to
> > > "swap suspend", and submit patches to fix it. Its going to be
> > > slightly more complicated, through...
> >
> > People have suggested that I incorporate swsusp2. Where does
> > this fit into things?
>
> I believe that you don't want swsusp2 in 2.6. It has hooks all over
> the place:
>
but maybe that's just why it happens to work for way many more people?
Or does anyone care about that?
Fedor
PS. Sorry, just my 2 cents
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFAVlk3w4m50RG4juoRAt8bAJ95Xl08+o5qhbWINtjnYbMdLlpRbwCeL9n+
7d5IsT79sCTSi36oF7od6Bs=
=aIb4
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Remove pmdisk from kernel
[not found] ` <20040316091648.GB6301@pern.dea.icai.upco.es>
@ 2004-03-16 10:11 ` Pavel Machek
2004-03-18 8:00 ` Romano Giannetti
1 sibling, 0 replies; 14+ messages in thread
From: Pavel Machek @ 2004-03-16 10:11 UTC (permalink / raw)
To: Romano Giannetti, linux-kernel, Andrew Morton, Patrick Mochel
On Út 16-03-04 10:16:48, Romano Giannetti wrote:
> On Mon, Mar 15, 2004 at 09:57:52PM +0100, Pavel Machek wrote:
> > Hi!
> > > Pavel Machek <pavel@ucw.cz> wrote:
> > > >
> > > > This removes pmdisk from kernel.
> > >
>
> Are you sure swsusp is equivalent? Last time I tried (2.6.1, I am in serious
> time shortage in this period) swsusp did not work on my Vaio fx-701, while
> PMDISK yes (ACPI enabled). I will try to test again in this weekend.
Yes, I'm pretty sure. There may be some bug in both of them, but they
do the same thing. (And swsusp should have slightly lower ammount of
bugs).
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Remove pmdisk from kernel
2004-03-15 23:27 ` Nigel Cunningham
@ 2004-03-16 10:17 ` Pavel Machek
2004-03-16 19:37 ` Nigel Cunningham
0 siblings, 1 reply; 14+ messages in thread
From: Pavel Machek @ 2004-03-16 10:17 UTC (permalink / raw)
To: Nigel Cunningham; +Cc: Andrew Morton, Linux Kernel Mailing List, Patrick Mochel
On Út 16-03-04 12:27:36, Nigel Cunningham wrote:
> On Tue, 2004-03-16 at 13:56, Pavel Machek wrote:
> >
> > > Most of those changes are hooks to make the freezer for more reliable.
> > > That part of the functionality could be isolated from the bulk of
> > > suspend2. Would that make you happy?
> >
> > Yes, that would be very good. It would make it easy to see actual
> > changes..
> >
> > [I still do not understand why those hooks are neccessary... kill
> > -SIGSTOP works, right?]
>
> Not always. Take for example the case where you have an NFS mount and
> happen to be doing an ls when the suspend cycle is started. If you
> signal the NFSd threads before the ls thread, the NFS threads will
> refrigerate okay, but the ls thread will fail to stop because it's
> waiting for data from the nfsd threads.
Hmm, you are right that with dead nfs server, kill -SIGSTOP will fail
on ls, and similary current refrigerator will fail. I think we can
live with that.
I agree that two-stage suspend is probably neccessary (userland first,
kernel than); but that should be possible without that big changes,
right?
> The best way to test the reliability of the current freezer
> implementation is to grab Michael's test patches. They can load the
> system down with NFS access, kernel compiles, benchmarks and so on.
> You'll quickly see the freezer fail. My implementation handles those
> loads flawlessly, and where problems are found, they're easily fixed.
Your solution is more reliable, thats right.
Pavel
--
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Remove pmdisk from kernel
2004-03-16 10:17 ` Pavel Machek
@ 2004-03-16 19:37 ` Nigel Cunningham
0 siblings, 0 replies; 14+ messages in thread
From: Nigel Cunningham @ 2004-03-16 19:37 UTC (permalink / raw)
To: Pavel Machek; +Cc: Andrew Morton, Linux Kernel Mailing List, Patrick Mochel
Hi.
On Tue, 2004-03-16 at 23:17, Pavel Machek wrote:
> Hmm, you are right that with dead nfs server, kill -SIGSTOP will fail
> on ls, and similary current refrigerator will fail. I think we can
> live with that.
>
> I agree that two-stage suspend is probably neccessary (userland first,
> kernel than); but that should be possible without that big changes,
> right?
It would certainly be simple to change to a two stage freeze. I don't
think I've tried that, so I'll cut the code and give it a try.
Regards,
Nigel
--
Nigel Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6253 0250 (home)
Evolution (n): A hypothetical process whereby infinitely improbable events occur
with alarming frequency, order arises from chaos, and no one is given credit.
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Remove pmdisk from kernel
[not found] ` <20040316091648.GB6301@pern.dea.icai.upco.es>
2004-03-16 10:11 ` Pavel Machek
@ 2004-03-18 8:00 ` Romano Giannetti
1 sibling, 0 replies; 14+ messages in thread
From: Romano Giannetti @ 2004-03-18 8:00 UTC (permalink / raw)
To: linux-kernel, Pavel Machek, Andrew Morton, Patrick Mochel,
Nigel Cunningham
On Tue, Mar 16, 2004 at 10:16:48AM +0100, I wrote:
> Are you sure swsusp is equivalent? Last time I tried (2.6.1, I am in serious
> time shortage in this period) swsusp did not work on my Vaio fx-701, while
> PMDISK yes (ACPI enabled). I will try to test again in this weekend.
Well, I can confirm that, as Mr. Machek said, swsusp and pmdisk gave me the
same functionality on a Vaio fx-701 laptop. I do not know why 2.6.1 didn't
work, but there have been a lot of ACPI updates, maybe that's the key.
Before suspending I unload pcmcia, sound (alsa), autofs, and usb hid
modules. If someone is interested I canb try not to unload something an
report back what happens.
I will try during the long weekend (tomorrow's holiday here) the bleeding
edge patches from Nigel, and report back.
Thanks to all,
Romano
--
Romano Giannetti - Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416 fax +34 915 596 569
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2004-03-18 8:00 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-03-15 19:54 Remove pmdisk from kernel Pavel Machek
2004-03-15 20:53 ` Andrew Morton
2004-03-15 20:57 ` Pavel Machek
2004-03-15 21:21 ` Andrew Morton
2004-03-15 19:38 ` Nigel Cunningham
2004-03-15 21:53 ` Andrew Morton
2004-03-15 20:14 ` Nigel Cunningham
2004-03-16 0:56 ` Pavel Machek
2004-03-15 23:27 ` Nigel Cunningham
2004-03-16 10:17 ` Pavel Machek
2004-03-16 19:37 ` Nigel Cunningham
2004-03-16 1:32 ` Fedor Karpelevitch
[not found] ` <20040316091648.GB6301@pern.dea.icai.upco.es>
2004-03-16 10:11 ` Pavel Machek
2004-03-18 8:00 ` Romano Giannetti
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®