Hi everyone.
This set of patches represents the core of Suspend2's module support.
Suspend2 uses a strong internal API to separate the method of
determining the content of the image from the method by which it is saved.
The code for determining the content is part of the core of Suspend2, and
transformations (compression and/or encryption) and storage of the pages are
handled by 'modules'.
The name is currently mostly historical, from the time when these components
could be built as kernel modules. That function was dropped to help with
merging, but I'd like to reintroduce it later, since some embedded developers
want to use Suspend2 to improve boot times. If/when that happens, I'll do it
in a way that doesn't require as many exported symbols as was previously
required. For now, though, the name remains, along with a few functions that
are needed for building as modules. My expectation is that merging will take
some time; perhaps by that time, I'll have modular support back in, in a
better form.
Signed-off-by: Nigel Cunningham <[email protected]>
--
Nigel Cunningham nigel at suspend2 dot net http://suspend2.net
Suspend2 uses a strong internal API to separate the method of determining
the content of the image from the method by which it is saved. The code for
determining the content is part of the core of Suspend2, and
transformations (compression and/or encryption) and storage of the pages
are handled by 'modules'.
The name is currently mostly historical, from the time when these
components could be built as kernel modules. That function was dropped to
help with merging, but I'd like to reintroduce it later, since some
embedded developers want to use Suspend2 to improve boot times. If/when
that happens, I'll do it in a way that doesn't require as many exported
symbols as was previously required. For now, though, the name remains,
along with a few functions that are needed for building as modules. My
expectation is that merging will take some time; perhaps by that time, I'll
have modular support back in, in a better form.
Signed-off-by: Nigel Cunningham <[email protected]>
0 files changed, 0 insertions(+), 0 deletions(-)
--
Nigel Cunningham nigel at suspend2 dot net
Take or put a reference to a module, so it can't be unloaded while in use.
Signed-off-by: Nigel Cunningham <[email protected]>
kernel/power/modules.c | 38 ++++++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/kernel/power/modules.c b/kernel/power/modules.c
index a7c3c38..dd53b27 100644
--- a/kernel/power/modules.c
+++ b/kernel/power/modules.c
@@ -185,3 +185,41 @@ struct suspend_module_ops *get_next_filt
return active_writer;
}
+
+/* suspend2_get_modules
+ *
+ * Take a reference to modules so they can't go away under us.
+ */
+
+int suspend2_get_modules(void)
+{
+ struct suspend_module_ops *this_module;
+
+ list_for_each_entry(this_module, &suspend_modules, module_list) {
+ if (!try_module_get(this_module->module)) {
+ /* Failed! Reverse gets and return error */
+ struct suspend_module_ops *this_module2;
+ list_for_each_entry(this_module2, &suspend_modules, module_list) {
+ if (this_module == this_module2)
+ return -EINVAL;
+ module_put(this_module2->module);
+ }
+ }
+ }
+
+ return 0;
+}
+
+/* suspend2_put_modules
+ *
+ * Release our references to modules we used.
+ */
+
+void suspend2_put_modules(void)
+{
+ struct suspend_module_ops *this_module;
+
+ list_for_each_entry(this_module, &suspend_modules, module_list) {
+ module_put(this_module->module);
+ }
+}
--
Nigel Cunningham nigel at suspend2 dot net
Routines to tell modules that we're about to do some work, and conversely,
have finished our labours for the moment. We allow them to do some actions
only if we're starting/finishing a cycle by passing a flag to indicate
that.
Signed-off-by: Nigel Cunningham <[email protected]>
kernel/power/modules.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 49 insertions(+), 0 deletions(-)
diff --git a/kernel/power/modules.c b/kernel/power/modules.c
index f7e9ab0..eee5678 100644
--- a/kernel/power/modules.c
+++ b/kernel/power/modules.c
@@ -116,3 +116,52 @@ void suspend_move_module_tail(struct sus
if ((num_filters + num_writers + num_ui) > 1)
list_move_tail(&module->module_list, &suspend_modules);
}
+
+/*
+ * suspend2_initialise_modules
+ *
+ * Get ready to do some work!
+ */
+int suspend2_initialise_modules(int starting_cycle)
+{
+ struct suspend_module_ops *this_module;
+ int result;
+
+ list_for_each_entry(this_module, &suspend_modules, module_list) {
+ if (this_module->disabled)
+ continue;
+ if (this_module->initialise) {
+ suspend_message(SUSPEND_MEMORY, SUSPEND_MEDIUM, 1,
+ "Initialising module %s.\n",
+ this_module->name);
+ if ((result = this_module->initialise(starting_cycle))) {
+ printk("%s didn't initialise okay.\n",
+ this_module->name);
+ return result;
+ }
+ }
+ }
+
+ return 0;
+}
+
+/*
+ * suspend2_cleanup_modules
+ *
+ * Tell modules the work is done.
+ */
+void suspend2_cleanup_modules(int finishing_cycle)
+{
+ struct suspend_module_ops *this_module;
+
+ list_for_each_entry(this_module, &suspend_modules, module_list) {
+ if (this_module->disabled)
+ continue;
+ if (this_module->cleanup) {
+ suspend_message(SUSPEND_MEMORY, SUSPEND_MEDIUM, 1,
+ "Cleaning up module %s.\n",
+ this_module->name);
+ this_module->cleanup(finishing_cycle);
+ }
+ }
+}
--
Nigel Cunningham nigel at suspend2 dot net
Calculate the space in an image header required for storing module
configuration data.
Signed-off-by: Nigel Cunningham <[email protected]>
kernel/power/modules.c | 21 +++++++++++++++++++++
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/kernel/power/modules.c b/kernel/power/modules.c
index dd53b27..7d56ce0 100644
--- a/kernel/power/modules.c
+++ b/kernel/power/modules.c
@@ -16,6 +16,27 @@ static int num_filters = 0, num_ui = 0;
int num_writers = 0, num_modules = 0;
/*
+ * header_storage_for_modules
+ *
+ * Returns the amount of space needed to store configuration
+ * data needed by the modules prior to copying back the original
+ * kernel. We can exclude data for pageset2 because it will be
+ * available anyway once the kernel is copied back.
+ */
+unsigned long header_storage_for_modules(void)
+{
+ struct suspend_module_ops *this_module;
+ unsigned long bytes = 0;
+
+ list_for_each_entry(this_module, &suspend_modules, module_list) {
+ if (this_module->disabled)
+ continue;
+ if (this_module->storage_needed)
+ bytes += this_module->storage_needed();
+ }
+
+ return bytes;
+}
* suspend_register_module
*
* Register a module.
--
Nigel Cunningham nigel at suspend2 dot net
Given a current (possibly NULL) pointer to a module, find the next module
in the pipeline.
Signed-off-by: Nigel Cunningham <[email protected]>
kernel/power/modules.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/kernel/power/modules.c b/kernel/power/modules.c
index eee5678..a7c3c38 100644
--- a/kernel/power/modules.c
+++ b/kernel/power/modules.c
@@ -165,3 +165,23 @@ void suspend2_cleanup_modules(int finish
}
}
}
+
+/*
+ * get_next_filter
+ *
+ * Get the next filter in the pipeline.
+ */
+struct suspend_module_ops *get_next_filter(struct suspend_module_ops *filter_sought)
+{
+ struct suspend_module_ops *last_filter = NULL, *this_filter = NULL;
+
+ list_for_each_entry(this_filter, &suspend_filters, ops.filter.filter_list) {
+ if (this_filter->disabled)
+ continue;
+ if ((last_filter == filter_sought) || (!filter_sought))
+ return this_filter;
+ last_filter = this_filter;
+ }
+
+ return active_writer;
+}
--
Nigel Cunningham nigel at suspend2 dot net
This function moves a module to the tail of lists in which it appears. This
is used at resume time, to make the order in which modules are used match
the order used when suspending. It wouldn't do to compress and then encrypt
while suspending, but try to decompress before decrypting at resume.
Signed-off-by: Nigel Cunningham <[email protected]>
kernel/power/modules.c | 31 +++++++++++++++++++++++++++++++
1 files changed, 31 insertions(+), 0 deletions(-)
diff --git a/kernel/power/modules.c b/kernel/power/modules.c
index 227e320..f7e9ab0 100644
--- a/kernel/power/modules.c
+++ b/kernel/power/modules.c
@@ -85,3 +85,34 @@ void suspend_unregister_module(struct su
list_del(&module->module_list);
num_modules--;
}
+
+/*
+ * suspend_move_module_tail
+ *
+ * Rearrange modules when reloading the config.
+ */
+void suspend_move_module_tail(struct suspend_module_ops *module)
+{
+ switch (module->type) {
+ case FILTER_PLUGIN:
+ if (num_filters > 1)
+ list_move_tail(&module->ops.filter.filter_list,
+ &suspend_filters);
+ break;
+
+ case WRITER_PLUGIN:
+ if (num_writers > 1)
+ list_move_tail(&module->ops.writer.writer_list,
+ &suspend_writers);
+ break;
+
+ case MISC_PLUGIN:
+ break;
+ default:
+ printk("Hmmm. Plugin '%s' has an invalid type."
+ " It has been ignored.\n", module->name);
+ return;
+ }
+ if ((num_filters + num_writers + num_ui) > 1)
+ list_move_tail(&module->module_list, &suspend_modules);
+}
--
Nigel Cunningham nigel at suspend2 dot net
This patch implements registration and deregistration of modules that are
used for page transformation and storage.
Signed-off-by: Nigel Cunningham <[email protected]>
kernel/power/modules.c | 87 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 87 insertions(+), 0 deletions(-)
diff --git a/kernel/power/modules.c b/kernel/power/modules.c
new file mode 100644
index 0000000..227e320
--- /dev/null
+++ b/kernel/power/modules.c
@@ -0,0 +1,87 @@
+/*
+ * kernel/power/modules.c
+ *
+ * Copyright (C) 2004-2005 Nigel Cunningham <[email protected]>
+ *
+ */
+
+#include <linux/suspend.h>
+#include <linux/module.h>
+#include "suspend2.h"
+#include "modules.h"
+
+struct list_head suspend_filters, suspend_writers, suspend_modules;
+struct suspend_module_ops *active_writer = NULL;
+static int num_filters = 0, num_ui = 0;
+int num_writers = 0, num_modules = 0;
+
+/*
+ * suspend_register_module
+ *
+ * Register a module.
+ */
+int suspend_register_module(struct suspend_module_ops *module)
+{
+ if (find_module_given_name(module->name))
+ return -EBUSY;
+
+ switch (module->type) {
+ case FILTER_PLUGIN:
+ list_add_tail(&module->ops.filter.filter_list,
+ &suspend_filters);
+ num_filters++;
+ break;
+
+ case WRITER_PLUGIN:
+ list_add_tail(&module->ops.writer.writer_list,
+ &suspend_writers);
+ num_writers++;
+ break;
+
+ case MISC_PLUGIN:
+ break;
+
+ default:
+ printk("Hmmm. Plugin '%s' has an invalid type."
+ " It has been ignored.\n", module->name);
+ return -EINVAL;
+ }
+ list_add_tail(&module->module_list, &suspend_modules);
+ num_modules++;
+
+ return 0;
+}
+
+/*
+ * suspend_unregister_module
+ *
+ * Remove a module.
+ */
+void suspend_unregister_module(struct suspend_module_ops *module)
+{
+ switch (module->type) {
+ case FILTER_PLUGIN:
+ list_del(&module->ops.filter.filter_list);
+ num_filters--;
+ break;
+
+ case WRITER_PLUGIN:
+ list_del(&module->ops.writer.writer_list);
+ num_writers--;
+ if (active_writer == module) {
+ active_writer = NULL;
+ set_suspend_state(SUSPEND_DISABLED);
+ }
+ break;
+
+ case MISC_PLUGIN:
+ break;
+
+ default:
+ printk("Hmmm. Plugin '%s' has an invalid type."
+ " It has been ignored.\n", module->name);
+ return;
+ }
+ list_del(&module->module_list);
+ num_modules--;
+}
--
Nigel Cunningham nigel at suspend2 dot net
Given the name of a module, return a pointer to it, or NULL if not found.
This is used when reloading the configuration data at resume time.
Signed-off-by: Nigel Cunningham <[email protected]>
kernel/power/modules.c | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/kernel/power/modules.c b/kernel/power/modules.c
index 7d56ce0..63f9dbb 100644
--- a/kernel/power/modules.c
+++ b/kernel/power/modules.c
@@ -37,6 +37,26 @@ unsigned long header_storage_for_modules
return bytes;
}
+
+/* find_module_given_name
+ * Functionality : Return a module (if found), given a pointer
+ * to its name
+ */
+
+struct suspend_module_ops *find_module_given_name(char *name)
+{
+ struct suspend_module_ops *this_module, *found_module = NULL;
+
+ list_for_each_entry(this_module, &suspend_modules, module_list) {
+ if (!strcmp(name, this_module->name)) {
+ found_module = this_module;
+ break;
+ }
+ }
+
+ return found_module;
+}
+
* suspend_register_module
*
* Register a module.
--
Nigel Cunningham nigel at suspend2 dot net
Append the (textual) debugging output of each non-disabled module to a
buffer. This output should be short, so we don't get carried away
supporting multiple pages of output.
Signed-off-by: Nigel Cunningham <[email protected]>
kernel/power/modules.c | 24 ++++++++++++++++++++++++
1 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/kernel/power/modules.c b/kernel/power/modules.c
index 63f9dbb..9c27957 100644
--- a/kernel/power/modules.c
+++ b/kernel/power/modules.c
@@ -57,6 +57,30 @@ struct suspend_module_ops *find_module_g
return found_module;
}
+/*
+ * print_module_debug_info
+ * Functionality : Get debugging info from modules into a buffer.
+ */
+int print_module_debug_info(char *buffer, int buffer_size)
+{
+ struct suspend_module_ops *this_module;
+ int len = 0;
+
+ list_for_each_entry(this_module, &suspend_modules, module_list) {
+ if (this_module->disabled)
+ continue;
+ if (this_module->print_debug_info) {
+ int result;
+ result = this_module->print_debug_info(buffer + len,
+ buffer_size - len);
+ len += result;
+ }
+ }
+
+ return len;
+}
+
+/*
* suspend_register_module
*
* Register a module.
--
Nigel Cunningham nigel at suspend2 dot net
Calculate the amount of memory required for the modules that will be used.
Utilised when preparing to suspend, to ensure that we have sufficient
memory available for doing our work.
Signed-off-by: Nigel Cunningham <[email protected]>
kernel/power/modules.c | 22 ++++++++++++++++++++++
1 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/kernel/power/modules.c b/kernel/power/modules.c
index 9c27957..e7e7e93 100644
--- a/kernel/power/modules.c
+++ b/kernel/power/modules.c
@@ -38,6 +38,28 @@ unsigned long header_storage_for_modules
return bytes;
}
+/*
+ * memory_for_modules
+ *
+ * Returns the amount of memory requested by modules for
+ * doing their work during the cycle.
+ */
+
+unsigned long memory_for_modules(void)
+{
+ unsigned long bytes = 0;
+ struct suspend_module_ops *this_module;
+
+ list_for_each_entry(this_module, &suspend_modules, module_list) {
+ if (this_module->disabled)
+ continue;
+ if (this_module->memory_needed)
+ bytes += this_module->memory_needed();
+ }
+
+ return ((bytes + PAGE_SIZE - 1) >> PAGE_SHIFT);
+}
+
/* find_module_given_name
* Functionality : Return a module (if found), given a pointer
* to its name
--
Nigel Cunningham nigel at suspend2 dot net
On 2/1/06, Nigel Cunningham <[email protected]> wrote:
> Suspend2 uses a strong internal API to separate the method of determining
> the content of the image from the method by which it is saved. The code for
> determining the content is part of the core of Suspend2, and
> transformations (compression and/or encryption) and storage of the pages
> are handled by 'modules'.
[snip]
> Signed-off-by: Nigel Cunningham <[email protected]>
>
> 0 files changed, 0 insertions(+), 0 deletions(-)
Uh, oh, where's the patch?
Pekka
Hi,
On 2/1/06, Nigel Cunningham <[email protected]> wrote:
> +++ b/kernel/power/modules.c
> @@ -0,0 +1,87 @@
[snip]
> +
> +struct list_head suspend_filters, suspend_writers, suspend_modules;
> +struct suspend_module_ops *active_writer = NULL;
> +static int num_filters = 0, num_ui = 0;
> +int num_writers = 0, num_modules = 0;
Unneeded assignments, they're already guaranteed to be zeroed.
> + list_add_tail(&module->module_list, &suspend_modules);
> + num_modules++;
No locking, why?
Pekka
On 2/1/06, Nigel Cunningham <[email protected]> wrote:
> The name is currently mostly historical, from the time when these components
> could be built as kernel modules.
I think suspend_plugin would be a nicer name. Your code is even using
the term 'plugin' and 'filter' instead of module in many places.
Pekka
On Wednesday 01 February 2006 22:32, Pekka Enberg wrote:
> On 2/1/06, Nigel Cunningham <[email protected]> wrote:
> > Suspend2 uses a strong internal API to separate the method of determining
> > the content of the image from the method by which it is saved. The code
> > for determining the content is part of the core of Suspend2, and
> > transformations (compression and/or encryption) and storage of the pages
> > are handled by 'modules'.
>
> [snip]
>
> > Signed-off-by: Nigel Cunningham <[email protected]>
> >
> > 0 files changed, 0 insertions(+), 0 deletions(-)
>
> Uh, oh, where's the patch?
Indeed! Oops! I think I've managed to put this in kmail without having it mangled!
Nigel
[Suspend2] kernel/power/modules.h
Suspend2 uses a strong internal API to separate the method of determining
the content of the image from the method by which it is saved. The code for
determining the content is part of the core of Suspend2, and
transformations (compression and/or encryption) and storage of the pages
are handled by 'modules'.
The name is currently mostly historical, from the time when these
components could be built as kernel modules. That function was dropped to
help with merging, but I'd like to reintroduce it later, since some
embedded developers want to use Suspend2 to improve boot times. If/when
that happens, I'll do it in a way that doesn't require as many exported
symbols as was previously required. For now, though, the name remains,
along with a few functions that are needed for building as modules. My
expectation is that merging will take some time; perhaps by that time, I'll
have modular support back in, in a better form.
Signed-off-by: Nigel Cunningham <[email protected]>
---
commit a97697c4228b1f4daa0d692b373f3811bec9cb76
tree 8bf0c9e2bff6abe18ca410a14062a3e2ed8e4214
parent 424a2272be7e6858b3929bae5fbc645c35897482
author Nigel Cunningham <[email protected]> Wed, 01 Feb 2006 22:37:48 +1000
committer root <[email protected]> Wed, 01 Feb 2006 22:37:48 +1000
kernel/power/modules.h | 179 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 179 insertions(+), 0 deletions(-)
diff --git a/kernel/power/modules.h b/kernel/power/modules.h
new file mode 100644
index 0000000..ee34199
--- /dev/null
+++ b/kernel/power/modules.h
@@ -0,0 +1,179 @@
+/*
+ * kernel/power/module.h
+ *
+ * Copyright (C) 2004-2005 Nigel Cunningham <[email protected]>
+ *
+ * This file is released under the GPLv2.
+ *
+ * It contains declarations for modules. Plugins are additions to
+ * suspend2 that provide facilities such as image compression or
+ * encryption, backends for storage of the image and user interfaces.
+ *
+ */
+
+/* This is the maximum size we store in the image header for a module name */
+#define SUSPEND_MAX_PLUGIN_NAME_LENGTH 30
+
+/* Per-module metadata */
+struct module_header {
+ char name[SUSPEND_MAX_PLUGIN_NAME_LENGTH];
+ int disabled;
+ int type;
+ int index;
+ int data_length;
+ unsigned long signature;
+};
+
+extern int num_modules, num_writers;
+
+enum {
+ FILTER_PLUGIN,
+ WRITER_PLUGIN,
+ MISC_PLUGIN, // Block writer, eg.
+ CHECKSUM_PLUGIN
+};
+
+enum {
+ SUSPEND_ASYNC,
+ SUSPEND_SYNC
+};
+
+struct suspend_filter_ops {
+ /* Writing the image proper */
+ int (*write_chunk) (struct page *buffer_page);
+
+ /* Reading the image proper */
+ int (*read_chunk) (struct page *buffer_page, int sync);
+
+ /* Reset module if image exists but reading aborted */
+ void (*noresume_reset) (void);
+ struct list_head filter_list;
+};
+
+struct suspend_writer_ops {
+
+ /* Writing the image proper */
+ int (*write_chunk) (struct page *buffer_page);
+
+ /* Reading the image proper */
+ int (*read_chunk) (struct page *buffer_page, int sync);
+
+ /* Reset module if image exists but reading aborted */
+ void (*noresume_reset) (void);
+
+ /* Calls for allocating storage */
+
+ int (*storage_available) (void); // Maximum size of image we can save
+ // (incl. space already allocated).
+
+ int (*storage_allocated) (void);
+ // Amount of storage already allocated
+ int (*release_storage) (void);
+
+ /*
+ * Header space is allocated separately. Note that allocation
+ * of space for the header might result in allocated space
+ * being stolen from the main pool if there is no unallocated
+ * space. We have to be able to allocate enough space for
+ * the header. We can eat memory to ensure there is enough
+ * for the main pool.
+ */
+ int (*allocate_header_space) (int space_requested);
+ int (*allocate_storage) (int space_requested);
+
+ /* Read and write the metadata */
+ int (*write_header_init) (void);
+ int (*write_header_chunk) (char *buffer_start, int buffer_size);
+ int (*write_header_cleanup) (void);
+
+ int (*read_header_init) (void);
+ int (*read_header_chunk) (char *buffer_start, int buffer_size);
+ int (*read_header_cleanup) (void);
+
+ /* Prepare metadata to be saved (relativise/absolutise extents) */
+ int (*serialise_extents) (void);
+ int (*load_extents) (void);
+
+ /* Attempt to parse an image location */
+ int (*parse_sig_location) (char *buffer, int only_writer);
+
+ /* Determine whether image exists that we can restore */
+ int (*image_exists) (void);
+
+ /* Mark the image as having tried to resume */
+ void (*mark_resume_attempted) (void);
+
+ /* Destroy image if one exists */
+ int (*invalidate_image) (void);
+
+ /* Wait on I/O */
+ int (*wait_on_io) (int flush_all);
+
+ struct list_head writer_list;
+};
+
+struct suspend_module_ops {
+ /* Functions common to all modules */
+ int type;
+ char *name;
+ struct module *module;
+ int disabled;
+ struct list_head module_list;
+
+ /* Bytes! */
+ unsigned long (*memory_needed) (void);
+ unsigned long (*storage_needed) (void);
+
+ int (*print_debug_info) (char *buffer, int size);
+ int (*save_config_info) (char *buffer);
+ void (*load_config_info) (char *buffer, int len);
+
+ /* Initialise & cleanup - general routines called
+ * at the start and end of a cycle. */
+ int (*initialise) (int starting_cycle);
+ void (*cleanup) (int finishing_cycle);
+
+ int (*write_init) (int stream_number);
+ int (*write_cleanup) (void);
+
+ int (*read_init) (int stream_number);
+ int (*read_cleanup) (void);
+
+ union {
+ struct suspend_filter_ops filter;
+ struct suspend_writer_ops writer;
+ } ops;
+};
+
+extern struct suspend_module_ops *active_writer;
+extern struct list_head suspend_filters, suspend_writers, suspend_modules;
+
+extern void prepare_console_modules(void);
+extern void cleanup_console_modules(void);
+
+extern struct suspend_module_ops *find_module_given_name(char *name);
+extern struct suspend_module_ops *get_next_filter(struct suspend_module_ops *);
+
+extern int suspend_register_module(struct suspend_module_ops *module);
+extern void suspend_move_module_tail(struct suspend_module_ops *module);
+
+extern unsigned long header_storage_for_modules(void);
+extern unsigned long memory_for_modules(void);
+
+extern int print_module_debug_info(char *buffer, int buffer_size);
+extern int suspend_register_module(struct suspend_module_ops *module);
+extern void suspend_unregister_module(struct suspend_module_ops *module);
+
+extern int suspend2_initialise_modules(int starting_cycle);
+extern void suspend2_cleanup_modules(int finishing_cycle);
+
+int suspend2_get_modules(void);
+void suspend2_put_modules(void);
+
+static inline void suspend_initialise_module_lists(void) {
+ INIT_LIST_HEAD(&suspend_filters);
+ INIT_LIST_HEAD(&suspend_writers);
+ INIT_LIST_HEAD(&suspend_modules);
+}
+
+extern int expected_compression_ratio(void);
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Wednesday 01 February 2006 22:37, Pekka Enberg wrote:
> Hi,
>
> On 2/1/06, Nigel Cunningham <[email protected]> wrote:
> > +++ b/kernel/power/modules.c
> > @@ -0,0 +1,87 @@
>
> [snip]
>
> > +
> > +struct list_head suspend_filters, suspend_writers, suspend_modules;
> > +struct suspend_module_ops *active_writer = NULL;
> > +static int num_filters = 0, num_ui = 0;
> > +int num_writers = 0, num_modules = 0;
>
> Unneeded assignments, they're already guaranteed to be zeroed.
Good point. Will fix.
> > + list_add_tail(&module->module_list, &suspend_modules);
> > + num_modules++;
>
> No locking, why?
Not needed - the callers are _init routines only.
Regards,
Nigel
> Pekka
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Wednesday 01 February 2006 22:38, Pekka Enberg wrote:
> On 2/1/06, Nigel Cunningham <[email protected]> wrote:
> > The name is currently mostly historical, from the time when these
> > components could be built as kernel modules.
>
> I think suspend_plugin would be a nicer name. Your code is even using
> the term 'plugin' and 'filter' instead of module in many places.
Hmm. Thought I got rid of all mentions of 'plugin'. I was trying to follow
Dave M's advice from LCA :). Filters are slightly different - they're the
modules that do the encryption or compression, as opposed to the writers that
do the I/O.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On 2/1/06, Nigel Cunningham <[email protected]> wrote:
> --- /dev/null
> +++ b/kernel/power/modules.h
> +struct module_header {
[snip]
> +extern int num_modules, num_writers;
[snip]
> +extern struct suspend_module_ops *active_writer;
[snip]
> +extern void prepare_console_modules(void);
> +extern void cleanup_console_modules(void);
[snip, snip]
> +extern unsigned long header_storage_for_modules(void);
> +extern unsigned long memory_for_modules(void);
> +
> +extern int print_module_debug_info(char *buffer, int buffer_size);
Suspend prefix for the names of all of the above please? They're
confusing with kernel/module.c now.
> +extern int suspend_register_module(struct suspend_module_ops *module);
> +extern void suspend_unregister_module(struct suspend_module_ops *module);
> +
> +extern int suspend2_initialise_modules(int starting_cycle);
> +extern void suspend2_cleanup_modules(int finishing_cycle);
> +
> +int suspend2_get_modules(void);
> +void suspend2_put_modules(void);
I think we can call these suspend_{get|set}_modules instead i.e.
without the extra '2'.
> +
> +static inline void suspend_initialise_module_lists(void) {
> + INIT_LIST_HEAD(&suspend_filters);
> + INIT_LIST_HEAD(&suspend_writers);
> + INIT_LIST_HEAD(&suspend_modules);
> +}
I couldn't find a user for this. I would imagine there's only one,
though, and this should be inlined there?
Pekka
On Wed, 1 Feb 2006, Nigel Cunningham wrote:
> On Wednesday 01 February 2006 22:32, Pekka Enberg wrote:
> > On 2/1/06, Nigel Cunningham <[email protected]> wrote:
> > > Suspend2 uses a strong internal API to separate the method of determining
> > > the content of the image from the method by which it is saved. The code
> > > for determining the content is part of the core of Suspend2, and
> > > transformations (compression and/or encryption) and storage of the pages
> > > are handled by 'modules'.
> >
> > [snip]
> >
> > > Signed-off-by: Nigel Cunningham <[email protected]>
> > >
> > > 0 files changed, 0 insertions(+), 0 deletions(-)
> >
> > Uh, oh, where's the patch?
>
> Indeed! Oops! I think I've managed to put this in kmail without having it mangled!
>
> Nigel
>
>
> [Suspend2] kernel/power/modules.h
>
> kernel/power/modules.h | 179 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 files changed, 179 insertions(+), 0 deletions(-)
>
> diff --git a/kernel/power/modules.h b/kernel/power/modules.h
> new file mode 100644
> index 0000000..ee34199
> --- /dev/null
> +++ b/kernel/power/modules.h
> @@ -0,0 +1,179 @@
> +/*
> + * kernel/power/module.h
wrong file name.
> +enum {
> + FILTER_PLUGIN,
> + WRITER_PLUGIN,
> + MISC_PLUGIN, // Block writer, eg.
> + CHECKSUM_PLUGIN
> +};
Kernel comment style is /* ... */, not // (many places).
> + /* Bytes! */
Drop the '!'.
--
~Randy
Hi.
On Wednesday 01 February 2006 23:01, Pekka Enberg wrote:
> On 2/1/06, Nigel Cunningham <[email protected]> wrote:
> > --- /dev/null
> > +++ b/kernel/power/modules.h
> >
> > +struct module_header {
>
> [snip]
>
> > +extern int num_modules, num_writers;
>
> [snip]
>
> > +extern struct suspend_module_ops *active_writer;
>
> [snip]
>
> > +extern void prepare_console_modules(void);
> > +extern void cleanup_console_modules(void);
>
> [snip, snip]
>
> > +extern unsigned long header_storage_for_modules(void);
> > +extern unsigned long memory_for_modules(void);
> > +
> > +extern int print_module_debug_info(char *buffer, int buffer_size);
>
> Suspend prefix for the names of all of the above please? They're
> confusing with kernel/module.c now.
Fair enough. Will do.
> > +extern int suspend_register_module(struct suspend_module_ops *module);
> > +extern void suspend_unregister_module(struct suspend_module_ops
> > *module); +
> > +extern int suspend2_initialise_modules(int starting_cycle);
> > +extern void suspend2_cleanup_modules(int finishing_cycle);
> > +
> > +int suspend2_get_modules(void);
> > +void suspend2_put_modules(void);
>
> I think we can call these suspend_{get|set}_modules instead i.e.
> without the extra '2'.
I wanted to avoid confusion with similar routine names Pavel might use. For
example, he has a resume_setup and I have a resume2_setup.
> > +
> > +static inline void suspend_initialise_module_lists(void) {
> > + INIT_LIST_HEAD(&suspend_filters);
> > + INIT_LIST_HEAD(&suspend_writers);
> > + INIT_LIST_HEAD(&suspend_modules);
> > +}
>
> I couldn't find a user for this. I would imagine there's only one,
> though, and this should be inlined there?
Ok.
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Thursday 02 February 2006 03:12, Randy.Dunlap wrote:
> On Wed, 1 Feb 2006, Nigel Cunningham wrote:
> > On Wednesday 01 February 2006 22:32, Pekka Enberg wrote:
> > > On 2/1/06, Nigel Cunningham <[email protected]> wrote:
> > > > Suspend2 uses a strong internal API to separate the method of
> > > > determining the content of the image from the method by which it is
> > > > saved. The code for determining the content is part of the core of
> > > > Suspend2, and transformations (compression and/or encryption) and
> > > > storage of the pages are handled by 'modules'.
> > >
> > > [snip]
> > >
> > > > Signed-off-by: Nigel Cunningham <[email protected]>
> > > >
> > > > 0 files changed, 0 insertions(+), 0 deletions(-)
> > >
> > > Uh, oh, where's the patch?
> >
> > Indeed! Oops! I think I've managed to put this in kmail without having it
> > mangled!
> >
> > Nigel
> >
> >
> > [Suspend2] kernel/power/modules.h
> >
> > kernel/power/modules.h | 179
> > ++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 179
> > insertions(+), 0 deletions(-)
> >
> > diff --git a/kernel/power/modules.h b/kernel/power/modules.h
> > new file mode 100644
> > index 0000000..ee34199
> > --- /dev/null
> > +++ b/kernel/power/modules.h
> > @@ -0,0 +1,179 @@
> > +/*
> > + * kernel/power/module.h
>
> wrong file name.
Oops. Thanks.
> > +enum {
> > + FILTER_PLUGIN,
> > + WRITER_PLUGIN,
> > + MISC_PLUGIN, // Block writer, eg.
> > + CHECKSUM_PLUGIN
> > +};
>
> Kernel comment style is /* ... */, not // (many places).
Hmm. Learnt that a while ago. Not sure how I missed this one :)
> > + /* Bytes! */
>
> Drop the '!'.
:) Will do.
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On Wednesday 01 February 2006 23:01, Pekka Enberg wrote:
> > I think we can call these suspend_{get|set}_modules instead i.e.
> > without the extra '2'.
On 2/1/06, Nigel Cunningham <[email protected]> wrote:
> I wanted to avoid confusion with similar routine names Pavel might use. For
> example, he has a resume_setup and I have a resume2_setup.
Is that necessary for the mainline, though? We have only one suspend
in the kernel, not "Pavel suspend" and "Nigel suspend", right?
Pekka
Hi.
On Thursday 02 February 2006 07:45, Pekka Enberg wrote:
> On Wednesday 01 February 2006 23:01, Pekka Enberg wrote:
> > > I think we can call these suspend_{get|set}_modules instead i.e.
> > > without the extra '2'.
>
> On 2/1/06, Nigel Cunningham <[email protected]> wrote:
> > I wanted to avoid confusion with similar routine names Pavel might use.
> > For example, he has a resume_setup and I have a resume2_setup.
>
> Is that necessary for the mainline, though? We have only one suspend
> in the kernel, not "Pavel suspend" and "Nigel suspend", right?
Well, I'd love that to be true, but I don't believe Pavel's going to roll over
and say "Ok Nigel. You've got a better implementation. I'll submit patches to
remove mine." I might be wrong, and I hope I will be, but I fear they're
going to coexist for a while.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi,
On Wednesday 01 February 2006 23:55, Nigel Cunningham wrote:
> On Thursday 02 February 2006 07:45, Pekka Enberg wrote:
> > On Wednesday 01 February 2006 23:01, Pekka Enberg wrote:
> > > > I think we can call these suspend_{get|set}_modules instead i.e.
> > > > without the extra '2'.
> >
> > On 2/1/06, Nigel Cunningham <[email protected]> wrote:
> > > I wanted to avoid confusion with similar routine names Pavel might use.
> > > For example, he has a resume_setup and I have a resume2_setup.
> >
> > Is that necessary for the mainline, though? We have only one suspend
> > in the kernel, not "Pavel suspend" and "Nigel suspend", right?
>
> Well, I'd love that to be true, but I don't believe Pavel's going to roll over
> and say "Ok Nigel. You've got a better implementation. I'll submit patches to
> remove mine." I might be wrong, and I hope I will be, but I fear they're
> going to coexist for a while.
First, your code introduces many changes in many parts of the kernel,
so to merge it you'll have to ask many people for acceptance.
Second, swsusp is actively developed, not only by Pavel, and you know that,
so you could be nicer. ;-)
Still our approach is quite different to yours. We are focused on keepeing
the code possibly simple and non-intrusive wrt the other parts of the kernel,
whereas you seem to concentrate on features (which is not wrong, IMO, it's
just a different point of view). We're moving towards the implementation
of the features like the system image compression and encryption,
graphical progress meters etc. in the user space, which has some advantages,
and I think this approach is correct for a laptop/desktop system.
Its limitation , however, is that it requires a lot of memory for the system
memory snapshot which may be impractical for systems with limited RAM,
and that's where your solution may be required.
In conclusion, I see the room for both, as long as the do not conflict, so
could we please bury the hatched and start working _together_?
Greetings,
Rafael
Hi Rafael.
On Thursday 02 February 2006 18:31, Rafael J. Wysocki wrote:
> > Well, I'd love that to be true, but I don't believe Pavel's going to roll
> > over and say "Ok Nigel. You've got a better implementation. I'll submit
> > patches to remove mine." I might be wrong, and I hope I will be, but I
> > fear they're going to coexist for a while.
>
> First, your code introduces many changes in many parts of the kernel,
> so to merge it you'll have to ask many people for acceptance.
I really must work harder to get rid of that perception. It used to be the
case, but isn't nowadays. Just about all of suspend2's changes are new files
in kernel/power and include/<arch>/suspend2.h. The remainder are misc fixes,
and enhancements like Christoph's todo list.
> Second, swsusp is actively developed, not only by Pavel, and you know that,
> so you could be nicer. ;-)
It was hardly touched for a long time, but that has certainly been changing in
the last few months. I wasn't meaning to be uncharitable. Sorry for giving
that impression.
> Still our approach is quite different to yours. We are focused on keepeing
> the code possibly simple and non-intrusive wrt the other parts of the
> kernel, whereas you seem to concentrate on features (which is not wrong,
> IMO, it's just a different point of view). We're moving towards the
> implementation of the features like the system image compression and
> encryption,
> graphical progress meters etc. in the user space, which has some
> advantages, and I think this approach is correct for a laptop/desktop
> system.
>
> Its limitation , however, is that it requires a lot of memory for the
> system memory snapshot which may be impractical for systems with limited
> RAM, and that's where your solution may be required.
I'm more concerned about the security implications. I'll freely admit that I
haven't spent any real time looking at your code, but I'm concerned that the
additional functionality made available could be used by viruses and the
like. I'm sure you'd have to be root to do anything, but how could the
interfaces be misused?
> In conclusion, I see the room for both, as long as the do not conflict, so
> could we please bury the hatched and start working _together_?
I didn't realise I was holding one :). I'm not sure that I agree that there's
a need for both, but I have no desire whatsoever to act an any sort of nasty
way. All I want is to help provide Linux users with stable, reliable,
flexible and fast suspend-to-disk functionality.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi!
> Its limitation , however, is that it requires a lot of memory for the system
> memory snapshot which may be impractical for systems with limited RAM,
> and that's where your solution may be required.
Actually, suspend2 has similar limitation. It still needs half a
memory free, but it does not count caches into that as it can save
them separately.
That means that on certain small systems (32MB RAM?), suspend2 is going to
have big advantage of responsivity after resume. But on the systems
where [u]swsusp can't suspend (6MB RAM?), suspend2 is not going to be
able to suspend, either. [Roughly; due to bugs and implementation
differences there may be some system size where one works and second
one does not, but they are pretty similar]
But that's probably not a problem as it is only going to fail on
*very* small system. Desktops with 6MB RAM are not too common these
days, fortunately. Not even in embedded space.
Pavel
--
Thanks, Sharp!
On St 01-02-06 22:47:41, Nigel Cunningham wrote:
> Hi.
>
> On Wednesday 01 February 2006 22:37, Pekka Enberg wrote:
> > Hi,
> >
> > On 2/1/06, Nigel Cunningham <[email protected]> wrote:
> > > +++ b/kernel/power/modules.c
> > > @@ -0,0 +1,87 @@
> >
> > [snip]
> >
> > > +
> > > +struct list_head suspend_filters, suspend_writers, suspend_modules;
> > > +struct suspend_module_ops *active_writer = NULL;
> > > +static int num_filters = 0, num_ui = 0;
> > > +int num_writers = 0, num_modules = 0;
> >
> > Unneeded assignments, they're already guaranteed to be zeroed.
>
> Good point. Will fix.
>
> > > + list_add_tail(&module->module_list, &suspend_modules);
> > > + num_modules++;
> >
> > No locking, why?
>
> Not needed - the callers are _init routines only.
And insmod?
Pavel
--
Thanks, Sharp!
Hi!
> This set of patches represents the core of Suspend2's module support.
>
> Suspend2 uses a strong internal API to separate the method of
> determining the content of the image from the method by which it is saved.
> The code for determining the content is part of the core of Suspend2, and
> transformations (compression and/or encryption) and storage of the pages are
> handled by 'modules'.
swsusp already has a very strong API to separate image writing from
image creation (in -mm patch, anyway). It is also very nice, just
read() from /dev/snapshot. Please use it.
Pavel
--
Thanks, Sharp!
On St 01-02-06 23:45:15, Pekka Enberg wrote:
> On Wednesday 01 February 2006 23:01, Pekka Enberg wrote:
> > > I think we can call these suspend_{get|set}_modules instead i.e.
> > > without the extra '2'.
>
> On 2/1/06, Nigel Cunningham <[email protected]> wrote:
> > I wanted to avoid confusion with similar routine names Pavel might use. For
> > example, he has a resume_setup and I have a resume2_setup.
>
> Is that necessary for the mainline, though? We have only one suspend
> in the kernel, not "Pavel suspend" and "Nigel suspend", right?
Actually plan is to only have "Rafael suspend" :-). That's basically
"Pavel suspend" minus the disk writing parts. That is *long* term.
Pavel
--
Thanks, Sharp!
Hi!
> > Still our approach is quite different to yours. We are focused on keepeing
> > the code possibly simple and non-intrusive wrt the other parts of the
> > kernel, whereas you seem to concentrate on features (which is not wrong,
> > IMO, it's just a different point of view). We're moving towards the
> > implementation of the features like the system image compression and
> > encryption,
> > graphical progress meters etc. in the user space, which has some
> > advantages, and I think this approach is correct for a laptop/desktop
> > system.
> >
> > Its limitation , however, is that it requires a lot of memory for the
> > system memory snapshot which may be impractical for systems with limited
> > RAM, and that's where your solution may be required.
>
> I'm more concerned about the security implications. I'll freely admit that I
> haven't spent any real time looking at your code, but I'm concerned that the
> additional functionality made available could be used by viruses and the
> like. I'm sure you'd have to be root to do anything, but how could the
> interfaces be misused?
In vanilla kernel userland suspend has no security implications: root
can just do what he wants in /dev/mem, anyway.
In fedora kernel, userland suspend can be [miss]used to snapshot an
image, modify it, and write it back. Fortunately, this is going to
take *long* time so people will notice. [Interface changed on DaveJ's
request, now we have separate device, we no longer mess with
/dev/mem]. And similar problem exists in suspend2 -- malicious
graphical progress bar could probably modify memory image on disk.
> > In conclusion, I see the room for both, as long as the do not conflict, so
> > could we please bury the hatched and start working _together_?
>
> I didn't realise I was holding one :). I'm not sure that I agree that there's
> a need for both, but I have no desire whatsoever to act an any sort of nasty
> way. All I want is to help provide Linux users with stable, reliable,
> flexible and fast suspend-to-disk functionality.
Please take a look at current -mm series. It has everything neccessary
for your goals.
Pavel
--
Thanks, Sharp!
Hi.
On Thursday 02 February 2006 20:16, Pavel Machek wrote:
> > I'm more concerned about the security implications. I'll freely admit
> > that I haven't spent any real time looking at your code, but I'm
> > concerned that the additional functionality made available could be used
> > by viruses and the like. I'm sure you'd have to be root to do anything,
> > but how could the interfaces be misused?
>
> In vanilla kernel userland suspend has no security implications: root
> can just do what he wants in /dev/mem, anyway.
Ok.
> In fedora kernel, userland suspend can be [miss]used to snapshot an
> image, modify it, and write it back. Fortunately, this is going to
> take *long* time so people will notice. [Interface changed on DaveJ's
> request, now we have separate device, we no longer mess with
> /dev/mem]. And similar problem exists in suspend2 -- malicious
> graphical progress bar could probably modify memory image on disk.
How? It's just an ordinary process with no special permissions or access to
memory. The communication between the userspace process and the kernel is in
the form of a netlink socket, with the only messages sent back and forth
being what should be displayed or what actions the user requested. Everything
related to preparing the image and performing the I/O is done in the kernel.
There's no way I can see that a malicious userspace program could modify
anything but its own memory.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Thursday 02 February 2006 19:38, Pavel Machek wrote:
> Hi!
>
> > Its limitation , however, is that it requires a lot of memory for the
> > system memory snapshot which may be impractical for systems with limited
> > RAM, and that's where your solution may be required.
>
> Actually, suspend2 has similar limitation. It still needs half a
> memory free, but it does not count caches into that as it can save
> them separately.
>
> That means that on certain small systems (32MB RAM?), suspend2 is going to
> have big advantage of responsivity after resume. But on the systems
> where [u]swsusp can't suspend (6MB RAM?), suspend2 is not going to be
> able to suspend, either. [Roughly; due to bugs and implementation
> differences there may be some system size where one works and second
> one does not, but they are pretty similar]
>
> But that's probably not a problem as it is only going to fail on
> *very* small system. Desktops with 6MB RAM are not too common these
> days, fortunately. Not even in embedded space.
Fully agree.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Thursday 02 February 2006 19:54, Pavel Machek wrote:
> On St 01-02-06 22:47:41, Nigel Cunningham wrote:
> > Hi.
> >
> > On Wednesday 01 February 2006 22:37, Pekka Enberg wrote:
> > > Hi,
> > >
> > > On 2/1/06, Nigel Cunningham <[email protected]> wrote:
> > > > +++ b/kernel/power/modules.c
> > > > @@ -0,0 +1,87 @@
> > >
> > > [snip]
> > >
> > > > +
> > > > +struct list_head suspend_filters, suspend_writers, suspend_modules;
> > > > +struct suspend_module_ops *active_writer = NULL;
> > > > +static int num_filters = 0, num_ui = 0;
> > > > +int num_writers = 0, num_modules = 0;
> > >
> > > Unneeded assignments, they're already guaranteed to be zeroed.
> >
> > Good point. Will fix.
> >
> > > > + list_add_tail(&module->module_list, &suspend_modules);
> > > > + num_modules++;
> > >
> > > No locking, why?
> >
> > Not needed - the callers are _init routines only.
>
> And insmod?
Not right now. As I said in the intro, I want to have building as modules
being an option again, but right now it's partially removed because of the
symbol exporting issue.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi!
> > > I'm more concerned about the security implications. I'll freely admit
> > > that I haven't spent any real time looking at your code, but I'm
> > > concerned that the additional functionality made available could be used
> > > by viruses and the like. I'm sure you'd have to be root to do anything,
> > > but how could the interfaces be misused?
> >
> > In vanilla kernel userland suspend has no security implications: root
> > can just do what he wants in /dev/mem, anyway.
>
> Ok.
>
> > In fedora kernel, userland suspend can be [miss]used to snapshot an
> > image, modify it, and write it back. Fortunately, this is going to
> > take *long* time so people will notice. [Interface changed on DaveJ's
> > request, now we have separate device, we no longer mess with
> > /dev/mem]. And similar problem exists in suspend2 -- malicious
> > graphical progress bar could probably modify memory image on disk.
>
> How? It's just an ordinary process with no special permissions or access to
> memory. The communication between the userspace process and the kernel is in
> the form of a netlink socket, with the only messages sent back and forth
> being what should be displayed or what actions the user requested. Everything
> related to preparing the image and performing the I/O is done in the kernel.
> There's no way I can see that a malicious userspace program could modify
> anything but its own memory.
Fedora people have some "interesting" ideas about security. They want
to prevent userland to modify kernel memory, root or not. AFAICS
progress bar helper could access kernel memory while it is on disk,
then wait for resume to pick up the modifications.
Pavel
--
Thanks, Sharp!
Hi.
On Thursday 02 February 2006 20:05, Pavel Machek wrote:
> Hi!
>
> > This set of patches represents the core of Suspend2's module support.
> >
> > Suspend2 uses a strong internal API to separate the method of
> > determining the content of the image from the method by which it is
> > saved. The code for determining the content is part of the core of
> > Suspend2, and transformations (compression and/or encryption) and storage
> > of the pages are handled by 'modules'.
>
> swsusp already has a very strong API to separate image writing from
> image creation (in -mm patch, anyway). It is also very nice, just
> read() from /dev/snapshot. Please use it.
You know that's not an option.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi!
> > > This set of patches represents the core of Suspend2's module support.
> > >
> > > Suspend2 uses a strong internal API to separate the method of
> > > determining the content of the image from the method by which it is
> > > saved. The code for determining the content is part of the core of
> > > Suspend2, and transformations (compression and/or encryption) and storage
> > > of the pages are handled by 'modules'.
> >
> > swsusp already has a very strong API to separate image writing from
> > image creation (in -mm patch, anyway). It is also very nice, just
> > read() from /dev/snapshot. Please use it.
>
> You know that's not an option.
No, I don't... please explain. Switching to this interface is going to
be easier than pushing suspend2 into kernel. Granted, end result may
not be suspend2, it may be something like suspend3, but it will be
better result than u-swsusp or suspend2 is today...
Pavel
--
Thanks, Sharp!
On Čt 02-02-06 20:38:11, Nigel Cunningham wrote:
> Hi.
>
> On Thursday 02 February 2006 20:05, Pavel Machek wrote:
> > Hi!
> >
> > > This set of patches represents the core of Suspend2's module support.
> > >
> > > Suspend2 uses a strong internal API to separate the method of
> > > determining the content of the image from the method by which it is
> > > saved. The code for determining the content is part of the core of
> > > Suspend2, and transformations (compression and/or encryption) and storage
> > > of the pages are handled by 'modules'.
> >
> > swsusp already has a very strong API to separate image writing from
> > image creation (in -mm patch, anyway). It is also very nice, just
> > read() from /dev/snapshot. Please use it.
>
> You know that's not an option.
(You could even use /dev/snapshot from kernelspace... for tests or
something. But such patch is not going to be mergeable.)
Pavel
--
Thanks, Sharp!
Hi,
On St 01-02-06 23:45:15, Pekka Enberg wrote:
> > Is that necessary for the mainline, though? We have only one suspend
> > in the kernel, not "Pavel suspend" and "Nigel suspend", right?
On 2/2/06, Pavel Machek <[email protected]> wrote:
> Actually plan is to only have "Rafael suspend" :-). That's basically
> "Pavel suspend" minus the disk writing parts. That is *long* term.
So what's the plan for short-term? Are userspace suspend and suspend
modules mutually exclusive or can they co-exist?
Pekka
Hi!
> On St 01-02-06 23:45:15, Pekka Enberg wrote:
> > > Is that necessary for the mainline, though? We have only one suspend
> > > in the kernel, not "Pavel suspend" and "Nigel suspend", right?
>
> On 2/2/06, Pavel Machek <[email protected]> wrote:
> > Actually plan is to only have "Rafael suspend" :-). That's basically
> > "Pavel suspend" minus the disk writing parts. That is *long* term.
>
> So what's the plan for short-term? Are userspace suspend and suspend
> modules mutually exclusive or can they co-exist?
They can coexist for as long as neccessary. (At one point, it was even
possible to suspend using userland code, then resume using kernel code
:-).
When I found out noone is really using kernel code any more (2.8.0 or
something), I'd like to get rid of it.
Pavel
--
Thanks, Sharp!
Hi,
On St 01-02-06 23:45:15, Pekka Enberg wrote:
> > So what's the plan for short-term? Are userspace suspend and suspend
> > modules mutually exclusive or can they co-exist?
On 2/2/06, Pavel Machek <[email protected]> wrote:
> They can coexist for as long as neccessary. (At one point, it was even
> possible to suspend using userland code, then resume using kernel code
> :-).
>
> When I found out noone is really using kernel code any more (2.8.0 or
> something), I'd like to get rid of it.
So are you saying we should pursue merging Suspend2 bits in the
mainline and deprecate it when userspace is mature enough and has all
the same features? Seems counter-productive but then again I am mostly
clueless of suspend issues.
Pekka
Hi.
On Thursday 02 February 2006 20:39, Pavel Machek wrote:
> Hi!
>
> > > > I'm more concerned about the security implications. I'll freely admit
> > > > that I haven't spent any real time looking at your code, but I'm
> > > > concerned that the additional functionality made available could be
> > > > used by viruses and the like. I'm sure you'd have to be root to do
> > > > anything, but how could the interfaces be misused?
> > >
> > > In vanilla kernel userland suspend has no security implications: root
> > > can just do what he wants in /dev/mem, anyway.
> >
> > Ok.
> >
> > > In fedora kernel, userland suspend can be [miss]used to snapshot an
> > > image, modify it, and write it back. Fortunately, this is going to
> > > take *long* time so people will notice. [Interface changed on DaveJ's
> > > request, now we have separate device, we no longer mess with
> > > /dev/mem]. And similar problem exists in suspend2 -- malicious
> > > graphical progress bar could probably modify memory image on disk.
> >
> > How? It's just an ordinary process with no special permissions or access
> > to memory. The communication between the userspace process and the kernel
> > is in the form of a netlink socket, with the only messages sent back and
> > forth being what should be displayed or what actions the user requested.
> > Everything related to preparing the image and performing the I/O is done
> > in the kernel. There's no way I can see that a malicious userspace
> > program could modify anything but its own memory.
>
> Fedora people have some "interesting" ideas about security. They want
> to prevent userland to modify kernel memory, root or not. AFAICS
> progress bar helper could access kernel memory while it is on disk,
> then wait for resume to pick up the modifications.
Hi again.
Maybe I'm just being thick, but I don't see what you mean by "progress bar
helper could access kernel memory while it is on disk". I suppose it could
potentially be given some means of writing directly to the disk that bypassed
filesystem code (remember that filesystems are frozen), but even if it could
overwrite a page of the image, most Suspend2 users compress the image, and
the corruption would be detected at resume time because the data wouldn't
decompress properly. The hypothetical malicious program wouldn't be able to
assume that blocks are page aligned, or that a particular compression method
was used. Encryption might also be used, and that could be using any of the
cryptoapi modules in any valid configuration.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Thursday 02 February 2006 20:47, Pavel Machek wrote:
> Hi!
>
> > > > This set of patches represents the core of Suspend2's module support.
> > > >
> > > > Suspend2 uses a strong internal API to separate the method of
> > > > determining the content of the image from the method by which it is
> > > > saved. The code for determining the content is part of the core of
> > > > Suspend2, and transformations (compression and/or encryption) and
> > > > storage of the pages are handled by 'modules'.
> > >
> > > swsusp already has a very strong API to separate image writing from
> > > image creation (in -mm patch, anyway). It is also very nice, just
> > > read() from /dev/snapshot. Please use it.
> >
> > You know that's not an option.
>
> No, I don't... please explain. Switching to this interface is going to
> be easier than pushing suspend2 into kernel. Granted, end result may
> not be suspend2, it may be something like suspend3, but it will be
> better result than u-swsusp or suspend2 is today...
It's not an option because I'm not trying not to step all over your codebase,
because I'm not moving suspend2 to userspace and because it doesn't make
sense to add another layer of abstraction by sticking /dev/snapshot in the
middle of kernel space code. There may be more reasons, but I haven't looked
at the /dev/snapshot code at all.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Thursday 02 February 2006 03:12, Randy.Dunlap wrote:
> On Wed, 1 Feb 2006, Nigel Cunningham wrote:
> > On Wednesday 01 February 2006 22:32, Pekka Enberg wrote:
> > > On 2/1/06, Nigel Cunningham <[email protected]> wrote:
> > > > Suspend2 uses a strong internal API to separate the method of
> > > > determining the content of the image from the method by which it is
> > > > saved. The code for determining the content is part of the core of
> > > > Suspend2, and transformations (compression and/or encryption) and
> > > > storage of the pages are handled by 'modules'.
> > >
> > > [snip]
> > >
> > > > Signed-off-by: Nigel Cunningham <[email protected]>
> > > >
> > > > 0 files changed, 0 insertions(+), 0 deletions(-)
> > >
> > > Uh, oh, where's the patch?
> >
> > Indeed! Oops! I think I've managed to put this in kmail without having it
> > mangled!
> >
> > Nigel
> >
> >
> > [Suspend2] kernel/power/modules.h
> >
> > kernel/power/modules.h | 179
> > ++++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 179
> > insertions(+), 0 deletions(-)
> >
> > diff --git a/kernel/power/modules.h b/kernel/power/modules.h
> > new file mode 100644
> > index 0000000..ee34199
> > --- /dev/null
> > +++ b/kernel/power/modules.h
> > @@ -0,0 +1,179 @@
> > +/*
> > + * kernel/power/module.h
>
> wrong file name.
>
> > +enum {
> > + FILTER_PLUGIN,
> > + WRITER_PLUGIN,
> > + MISC_PLUGIN, // Block writer, eg.
> > + CHECKSUM_PLUGIN
> > +};
>
> Kernel comment style is /* ... */, not // (many places).
>
> > + /* Bytes! */
>
> Drop the '!'.
All done. Thanks.
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On Čt 02-02-06 13:16:40, Pekka Enberg wrote:
> Hi,
>
> On St 01-02-06 23:45:15, Pekka Enberg wrote:
> > > So what's the plan for short-term? Are userspace suspend and suspend
> > > modules mutually exclusive or can they co-exist?
>
> On 2/2/06, Pavel Machek <[email protected]> wrote:
> > They can coexist for as long as neccessary. (At one point, it was even
> > possible to suspend using userland code, then resume using kernel code
> > :-).
> >
> > When I found out noone is really using kernel code any more (2.8.0 or
> > something), I'd like to get rid of it.
>
> So are you saying we should pursue merging Suspend2 bits in the
> mainline and deprecate it when userspace is mature enough and has all
> the same features? Seems counter-productive but then again I am mostly
> clueless of suspend issues.
No, I'm saying that suspend2 bits should be moved into userspace. That
way we get mature userspace much faster, without any big merge into
kernel.
Pavel
--
Thanks, Sharp!
Hi!
> > > > In fedora kernel, userland suspend can be [miss]used to snapshot an
> > > > image, modify it, and write it back. Fortunately, this is going to
> > > > take *long* time so people will notice. [Interface changed on DaveJ's
> > > > request, now we have separate device, we no longer mess with
> > > > /dev/mem]. And similar problem exists in suspend2 -- malicious
> > > > graphical progress bar could probably modify memory image on disk.
> > >
> > > How? It's just an ordinary process with no special permissions or access
> > > to memory. The communication between the userspace process and the kernel
> > > is in the form of a netlink socket, with the only messages sent back and
> > > forth being what should be displayed or what actions the user requested.
> > > Everything related to preparing the image and performing the I/O is done
> > > in the kernel. There's no way I can see that a malicious userspace
> > > program could modify anything but its own memory.
> >
> > Fedora people have some "interesting" ideas about security. They want
> > to prevent userland to modify kernel memory, root or not. AFAICS
> > progress bar helper could access kernel memory while it is on disk,
> > then wait for resume to pick up the modifications.
>
> Hi again.
>
> Maybe I'm just being thick, but I don't see what you mean by "progress bar
> helper could access kernel memory while it is on disk". I suppose it could
> potentially be given some means of writing directly to the disk that bypassed
> filesystem code (remember that filesystems are frozen), but even if it could
> overwrite a page of the image, most Suspend2 users compress the image, and
...yep, I said that fedora people have ""interesting"" ideas about
security :-).
Pavel
--
Thanks, Sharp!
Hi,
On 2/2/06, Nigel Cunningham <[email protected]> wrote:
> It's not an option because I'm not trying not to step all over your codebase,
> because I'm not moving suspend2 to userspace and because it doesn't make
> sense to add another layer of abstraction by sticking /dev/snapshot in the
> middle of kernel space code. There may be more reasons, but I haven't looked
> at the /dev/snapshot code at all.
Any technical reasons why suspend modules shouldn't be in userspace? I
can understand that you're not keen on redoing them but that's not an
argument for inclusion in the mainline.
Pekka
On Čt 02-02-06 21:31:55, Nigel Cunningham wrote:
> Hi.
>
> On Thursday 02 February 2006 20:47, Pavel Machek wrote:
> > Hi!
> >
> > > > swsusp already has a very strong API to separate image writing from
> > > > image creation (in -mm patch, anyway). It is also very nice, just
> > > > read() from /dev/snapshot. Please use it.
> > >
> > > You know that's not an option.
> >
> > No, I don't... please explain. Switching to this interface is going to
> > be easier than pushing suspend2 into kernel. Granted, end result may
> > not be suspend2, it may be something like suspend3, but it will be
> > better result than u-swsusp or suspend2 is today...
>
> It's not an option because I'm not trying not to step all over your codebase,
> because I'm not moving suspend2 to userspace and because it doesn't make
> sense to add another layer of abstraction by sticking /dev/snapshot in the
> middle of kernel space code. There may be more reasons, but I haven't looked
> at the /dev/snapshot code at all.
Please take a look at /dev/snapshot.
Parse error at the first sentence (too many nots), anyway:
1) we do not want two implementations of same code in kernel. [swsusp
vs. pmdisk was a mess]
2) we are not going to merge code into kernel, when it is possible to
do same thing in userspace. (*)
3) backwards compatibility is important in stable series.
4) merging code into kernel is a lot of work.
I do not think I want to remove swsusp from kernel. Even if I wanted
to, there's 3). That means suspend2 should not go in (see 1). Even if I
removed swsusp from kernel, suspend2 is not going to be merged,
because of 2). Even if world somehow forgot that it is possible to do
suspend2 in userspace, merging 10K lines of code is (4) still lot of
work.
Oops, that looks bad for suspend2 merge. I really think you should
take a look at /dev/snapshot. Unless it is terminally broken, I can't
see how suspend2 could be merged.
Pavel
(*) or very close to same thing. We still can't save memory full of caches.
--
Thanks, Sharp!
Hi.
On Wednesday 01 February 2006 23:01, Pekka Enberg wrote:
> > +
> > +static inline void suspend_initialise_module_lists(void) {
> > + INIT_LIST_HEAD(&suspend_filters);
> > + INIT_LIST_HEAD(&suspend_writers);
> > + INIT_LIST_HEAD(&suspend_modules);
> > +}
>
> I couldn't find a user for this. I would imagine there's only one,
> though, and this should be inlined there?
I forgot to mention re this - yes, there's just one caller, in another set of
patches I'll send later (this was just the first set!). Having the function
to be inlined in this .h so that it's with other module specific code, and
then used in the caller once it has been #included, isn't that the right way
to do things?
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Wednesday 01 February 2006 23:01, Pekka Enberg wrote:
> On 2/1/06, Nigel Cunningham <[email protected]> wrote:
> > --- /dev/null
> > +++ b/kernel/power/modules.h
> >
> > +struct module_header {
>
> [snip]
>
> > +extern int num_modules, num_writers;
>
> [snip]
>
> > +extern struct suspend_module_ops *active_writer;
>
> [snip]
>
> > +extern void prepare_console_modules(void);
> > +extern void cleanup_console_modules(void);
>
> [snip, snip]
>
> > +extern unsigned long header_storage_for_modules(void);
> > +extern unsigned long memory_for_modules(void);
> > +
> > +extern int print_module_debug_info(char *buffer, int buffer_size);
>
> Suspend prefix for the names of all of the above please? They're
> confusing with kernel/module.c now.
>
> > +extern int suspend_register_module(struct suspend_module_ops *module);
> > +extern void suspend_unregister_module(struct suspend_module_ops
> > *module); +
> > +extern int suspend2_initialise_modules(int starting_cycle);
> > +extern void suspend2_cleanup_modules(int finishing_cycle);
> > +
> > +int suspend2_get_modules(void);
> > +void suspend2_put_modules(void);
>
> I think we can call these suspend_{get|set}_modules instead i.e.
> without the extra '2'.
>
> > +
> > +static inline void suspend_initialise_module_lists(void) {
> > + INIT_LIST_HEAD(&suspend_filters);
> > + INIT_LIST_HEAD(&suspend_writers);
> > + INIT_LIST_HEAD(&suspend_modules);
> > +}
>
> I couldn't find a user for this. I would imagine there's only one,
> though, and this should be inlined there?
All done. Thanks!
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Thursday 02 February 2006 21:59, Pavel Machek wrote:
> On Čt 02-02-06 21:31:55, Nigel Cunningham wrote:
> > Hi.
> >
> > On Thursday 02 February 2006 20:47, Pavel Machek wrote:
> > > Hi!
> > >
> > > > > swsusp already has a very strong API to separate image writing from
> > > > > image creation (in -mm patch, anyway). It is also very nice, just
> > > > > read() from /dev/snapshot. Please use it.
> > > >
> > > > You know that's not an option.
> > >
> > > No, I don't... please explain. Switching to this interface is going to
> > > be easier than pushing suspend2 into kernel. Granted, end result may
> > > not be suspend2, it may be something like suspend3, but it will be
> > > better result than u-swsusp or suspend2 is today...
> >
> > It's not an option because I'm not trying not to step all over your
> > codebase, because I'm not moving suspend2 to userspace and because it
> > doesn't make sense to add another layer of abstraction by sticking
> > /dev/snapshot in the middle of kernel space code. There may be more
> > reasons, but I haven't looked at the /dev/snapshot code at all.
>
> Please take a look at /dev/snapshot.
>
> Parse error at the first sentence (too many nots), anyway:
>
> 1) we do not want two implementations of same code in kernel. [swsusp
> vs. pmdisk was a mess]
>
> 2) we are not going to merge code into kernel, when it is possible to
> do same thing in userspace. (*)
>
> 3) backwards compatibility is important in stable series.
>
> 4) merging code into kernel is a lot of work.
>
> I do not think I want to remove swsusp from kernel. Even if I wanted
> to, there's 3). That means suspend2 should not go in (see 1). Even if I
> removed swsusp from kernel, suspend2 is not going to be merged,
> because of 2). Even if world somehow forgot that it is possible to do
> suspend2 in userspace, merging 10K lines of code is (4) still lot of
> work.
>
> Oops, that looks bad for suspend2 merge. I really think you should
> take a look at /dev/snapshot. Unless it is terminally broken, I can't
> see how suspend2 could be merged.
I don't want to argue Pavel. I want to give users the best suspend to disk
implementation they can get. If you want to argue, you can do so with
yourself. Meanwhile, I'll work on getting Suspend2 ready for merging, and let
Andrew and Linus decide what they think should happen. If they want to step
in now and tell me not to bother, I'll happily listen and just maintain the
patches out of kernel until you and Rafael get swsusp up to scratch. I'll
even cc them now so they can have the opportunity to tell me not to bother.
But that's not what I've heard so far. In previous correspondence between us,
Andrew has seemed keen to get a better implementation in, and Linus said
something to the effect of "I'm sold" when I gave him an impromptu demo last
week at LCA (Linus, if you read this, feel free to tell me if my memory is
faulty and I'm putting words in your mouth).
As to backwards compatability, that shouldn't be hard to do.
Regards,
Nigel
> Pavel
> (*) or very close to same thing. We still can't save memory full of caches.
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Thursday 02 February 2006 21:44, Pekka Enberg wrote:
> Hi,
>
> On 2/2/06, Nigel Cunningham <[email protected]> wrote:
> > It's not an option because I'm not trying not to step all over your
> > codebase, because I'm not moving suspend2 to userspace and because it
> > doesn't make sense to add another layer of abstraction by sticking
> > /dev/snapshot in the middle of kernel space code. There may be more
> > reasons, but I haven't looked at the /dev/snapshot code at all.
>
> Any technical reasons why suspend modules shouldn't be in userspace? I
> can understand that you're not keen on redoing them but that's not an
> argument for inclusion in the mainline.
They're using cryptoapi to do the compression and encryption, and bio to do
the I/O. Moving this to userspace will add extra complexity and of course
slow down the process. It will also mean that to suspend and resume, the user
will be unconditionally required to have an initrd or initramfs. This is
already the case for the more complicated configurations (LVM, encryption
with keys that need to be entered at a prompt etc), but most people simply
use an unencrypted, compressed image on a swap partition and in that case do
not and should not need the added complication of configuring an initrd.
Shouldn't the question be "Why are we making this more complicated by moving
it to userspace?"
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On Wednesday 01 February 2006 23:01, Pekka Enberg wrote:
> > > +
> > > +static inline void suspend_initialise_module_lists(void) {
> > > + INIT_LIST_HEAD(&suspend_filters);
> > > + INIT_LIST_HEAD(&suspend_writers);
> > > + INIT_LIST_HEAD(&suspend_modules);
> > > +}
> >
> > I couldn't find a user for this. I would imagine there's only one,
> > though, and this should be inlined there?
On Thu, 2 Feb 2006, Nigel Cunningham wrote:
> I forgot to mention re this - yes, there's just one caller, in another set of
> patches I'll send later (this was just the first set!). Having the function
> to be inlined in this .h so that it's with other module specific code, and
> then used in the caller once it has been #included, isn't that the right way
> to do things?
Sorry, I can't parse the above :-). My point was that this is
probably called in a .c file so move the function in that file and
introduce it whenever you introduce the caller.
Pekka
On Thu, 2 Feb 2006, Nigel Cunningham wrote:
> Shouldn't the question be "Why are we making this more complicated by moving
> it to userspace?"
It's less code in kernel now and in the future, more flexible (we have
more options for compression and encryption in userspace), and less
invasive. Specific points that make Suspend2 less attractive: it's a lot
of code (500KB patch!), new compression code in kernel (LZF), dynamic page
flags, and the special userspace notification mechanism
(kernel/power/ui.c).
That being said, the biggest advantage for Suspend2 of course is that it's
ready and stable now.
Pekka
Hi Nigel,
On Thursday 02 February 2006 10:22, Nigel Cunningham wrote:
> On Thursday 02 February 2006 18:31, Rafael J. Wysocki wrote:
> > > Well, I'd love that to be true, but I don't believe Pavel's going to roll
> > > over and say "Ok Nigel. You've got a better implementation. I'll submit
> > > patches to remove mine." I might be wrong, and I hope I will be, but I
> > > fear they're going to coexist for a while.
> >
> > First, your code introduces many changes in many parts of the kernel,
> > so to merge it you'll have to ask many people for acceptance.
>
> I really must work harder to get rid of that perception. It used to be the
> case, but isn't nowadays. Just about all of suspend2's changes are new files
> in kernel/power and include/<arch>/suspend2.h. The remainder are misc fixes,
> and enhancements like Christoph's todo list.
Well, in your previous series of patches there are examples to the contrary,
like the changes to kthread_create() or workqueues. They would require an ack
from the maintainers of that code, at least.
Also, you probably need some changes in the arch code. If that is so, the
maintainers of relevant architectures should be asked.
That already is "many".
> > Second, swsusp is actively developed, not only by Pavel, and you know that,
> > so you could be nicer. ;-)
>
> It was hardly touched for a long time, but that has certainly been changing in
> the last few months. I wasn't meaning to be uncharitable. Sorry for giving
> that impression.
Accepted. :-)
> > Still our approach is quite different to yours. We are focused on keepeing
> > the code possibly simple and non-intrusive wrt the other parts of the
> > kernel, whereas you seem to concentrate on features (which is not wrong,
> > IMO, it's just a different point of view). We're moving towards the
> > implementation of the features like the system image compression and
> > encryption,
> > graphical progress meters etc. in the user space, which has some
> > advantages, and I think this approach is correct for a laptop/desktop
> > system.
> >
> > Its limitation , however, is that it requires a lot of memory for the
> > system memory snapshot which may be impractical for systems with limited
> > RAM, and that's where your solution may be required.
>
> I'm more concerned about the security implications. I'll freely admit that I
> haven't spent any real time looking at your code, but I'm concerned that the
> additional functionality made available could be used by viruses and the
> like. I'm sure you'd have to be root to do anything, but how could the
> interfaces be misused?
In not many ways, really. Of course you can do a DoS with them, but need
to be root to do this anyway.
> > In conclusion, I see the room for both, as long as the do not conflict, so
> > could we please bury the hatched and start working _together_?
>
> I didn't realise I was holding one :). I'm not sure that I agree that there's
> a need for both, but I have no desire whatsoever to act an any sort of nasty
> way. All I want is to help provide Linux users with stable, reliable,
> flexible and fast suspend-to-disk functionality.
That's fine. :-)
Obviously both solutions are used, so they both seem to be needed.
Greetings,
Rafael
Hi,
On Thursday 02 February 2006 10:38, Pavel Machek wrote:
> > Its limitation , however, is that it requires a lot of memory for the system
> > memory snapshot which may be impractical for systems with limited RAM,
> > and that's where your solution may be required.
>
> Actually, suspend2 has similar limitation. It still needs half a
> memory free, but it does not count caches into that as it can save
> them separately.
I didn't know that. [If that is the case, I wonder what Nigel means by
the "whole memory image". Nigel?]
> That means that on certain small systems (32MB RAM?), suspend2 is going to
> have big advantage of responsivity after resume. But on the systems
> where [u]swsusp can't suspend (6MB RAM?), suspend2 is not going to be
> able to suspend, either. [Roughly; due to bugs and implementation
> differences there may be some system size where one works and second
> one does not, but they are pretty similar]
Generally speaking, my perception is that suspend2 may be preferrable below
256 MB of RAM. Moreover there are some people who seem to prefer
entirely kernel-based suspend, and I'm not going to develop the code
in swap.c and disk.c any further (of course with the exception of bugfixes
etc.). Nigel has done it already so perhaps there is a room for his code,
too, _provided_ _that_ it is accepted.
Greetings,
Rafael
Hi!
> > Any technical reasons why suspend modules shouldn't be in userspace? I
> > can understand that you're not keen on redoing them but that's not an
> > argument for inclusion in the mainline.
>
> They're using cryptoapi to do the compression and encryption, and bio to do
> the I/O. Moving this to userspace will add extra complexity and of course
You are mostly using LZW, not supported by cryptoapi, anyway.
> slow down the process.
Slowdown will not be measurable, syscalls are cheap.
> Shouldn't the question be "Why are we making this more complicated by moving
> it to userspace?"
Because thats how the kernel works. We do not put random stuff into
kernel because someone happened to code it for kernelspace first. It
helps us with long-term sanity.
Pavel
--
Thanks, Sharp!
Hi!
> > Please take a look at /dev/snapshot.
> >
> > Parse error at the first sentence (too many nots), anyway:
> >
> > 1) we do not want two implementations of same code in kernel. [swsusp
> > vs. pmdisk was a mess]
> >
> > 2) we are not going to merge code into kernel, when it is possible to
> > do same thing in userspace. (*)
> >
> > 3) backwards compatibility is important in stable series.
> >
> > 4) merging code into kernel is a lot of work.
> >
> > I do not think I want to remove swsusp from kernel. Even if I wanted
> > to, there's 3). That means suspend2 should not go in (see 1). Even if I
> > removed swsusp from kernel, suspend2 is not going to be merged,
> > because of 2). Even if world somehow forgot that it is possible to do
> > suspend2 in userspace, merging 10K lines of code is (4) still lot of
> > work.
> >
> > Oops, that looks bad for suspend2 merge. I really think you should
> > take a look at /dev/snapshot. Unless it is terminally broken, I can't
> > see how suspend2 could be merged.
>
> I don't want to argue Pavel. I want to give users the best suspend to disk
> implementation they can get. If you want to argue, you can do so with
I want to create best suspen that can be still merged into kernel; I
guess thats the difference. Anyway I believe that most of suspend
should be done in userspace -- most of it can. But I guess you need to
hear it from Linus/Andrew, so...
> yourself. Meanwhile, I'll work on getting Suspend2 ready for merging, and let
> Andrew and Linus decide what they think should happen. If they want to step
> in now and tell me not to bother, I'll happily listen and just maintain the
Ahha, so that was the missing piece of puzzle.
Pavel
--
Thanks, Sharp!
On Thu, Feb 02, 2006 at 10:28:15PM +1000, Nigel Cunningham wrote:
> Shouldn't the question be "Why are we making this more complicated by moving
> it to userspace?"
Indeed. It seems that turning the kernel into Hurd is the latest fad.
One question I'm wondering about though is that 99% of the "suspend
doesn't work reliably" messages were answered by "it's a driver's
fault". I'm rather curious on how moving things to userspace is going
to fix that.
OG.
On Čt 02-02-06 16:43:19, Olivier Galibert wrote:
> On Thu, Feb 02, 2006 at 10:28:15PM +1000, Nigel Cunningham wrote:
> > Shouldn't the question be "Why are we making this more complicated by moving
> > it to userspace?"
>
> Indeed. It seems that turning the kernel into Hurd is the latest
> fad.
Heh, try reading suspend2.
> One question I'm wondering about though is that 99% of the "suspend
> doesn't work reliably" messages were answered by "it's a driver's
> fault". I'm rather curious on how moving things to userspace is going
> to fix that.
uswsusp is not going to fix driver's problems, but at least should not
add new problems. It is aimed at solving graphical bars, compression,
encryption etc.
Pavel
--
Thanks, Sharp!
On Thu, Feb 02, 2006 at 09:25:27PM +0100, Pavel Machek wrote:
> On Čt 02-02-06 16:43:19, Olivier Galibert wrote:
> > On Thu, Feb 02, 2006 at 10:28:15PM +1000, Nigel Cunningham wrote:
> > > Shouldn't the question be "Why are we making this more complicated by moving
> > > it to userspace?"
> >
> > Indeed. It seems that turning the kernel into Hurd is the latest
> > fad.
>
> Heh, try reading suspend2.
Can we leave the playground level insults off of linux-kernel please,
and keep the discussion at a technical level ?
Such remarks aren't furthering the cause of either implementation.
Dave
On Čt 02-02-06 15:31:55, Dave Jones wrote:
> On Thu, Feb 02, 2006 at 09:25:27PM +0100, Pavel Machek wrote:
> > On Čt 02-02-06 16:43:19, Olivier Galibert wrote:
> > > On Thu, Feb 02, 2006 at 10:28:15PM +1000, Nigel Cunningham wrote:
> > > > Shouldn't the question be "Why are we making this more complicated by moving
> > > > it to userspace?"
> > >
> > > Indeed. It seems that turning the kernel into Hurd is the latest
> > > fad.
> >
> > Heh, try reading suspend2.
>
> Can we leave the playground level insults off of linux-kernel please,
> and keep the discussion at a technical level ?
>
> Such remarks aren't furthering the cause of either implementation.
Well, Olivier said I'm turning kernel into Hurd. So he instead
advocates merging 10 000 lines of code (+7500, contains new
compression algorithm and new plugin architecture). I'd like to add
interface to userland (+300) and remove swap writing (long term,
-1000).
Olivier clearly did not see the patches; is asking him to learn what
he is talking about *that* much to ask?
Pavel
--
Thanks, Sharp!
Pavel Machek <[email protected]> wrote:
>
> > I don't want to argue Pavel. I want to give users the best suspend to disk
> > implementation they can get. If you want to argue, you can do so with
>
> I want to create best suspen that can be still merged into kernel; I
> guess thats the difference. Anyway I believe that most of suspend
> should be done in userspace -- most of it can. But I guess you need to
> hear it from Linus/Andrew, so...
You're unlikely to hear anything dispositive from either of us on this.
You three guys know far more than us about suspend, so it would be silly
for us to be making the technical decisions. When cornered, we're more
likely to come out with general kernel platitudes such as "doing it in
userspace:good" and "crashing the kernel:bad" and "incremental development
with early merges:good" and "mucking up the kernel source:bad".
What we hope and expect is that you'll come up with an agreed path in
accordance with general kernel coding and development principles. Linus
and I don't want to have to make tiebreak decisions - if we have to do
that, the system has failed.
Random thoughts:
- swsusp has been a multi-year ongoing source of churn and bug reports.
It hasn't been a big success and we have a way to go yet.
- People seem to be doing too much development on the swsusp core and not
enough development out where the actual problems are: drivers which don't
suspend and resume correctly.
- suspend2 is at a disadvantage because swsusp was merged first. If
neither of the solutions had been merged and if we were evaluating them
side-by-side, suspend2 would have a much better chance. This is a
problem.
- If you want my cheerfully uninformed opinion, we should toss both of
them out and implement suspend3, which is based on the kexec/kdump
infrastructure. There's so much duplication of intent here that it's not
funny. And having them separate like this weakens both in the area where
the real problems are: drivers.
- Justifying the inclusion of a feature by the appearance and usefulness
of the end result doesn't really work in this world. There are numerous
unmerged kernel features out there which work well and look great. But
we will look under the hood, and that's when problems start.
So, as promised, there's nothing useful here. What we'd most like to see
is for Nigel to start working on in-kernel swsusp, merging up the good bits
from suspend2 in some evolutionary incremental manner under which the
kernel continually improves. If, at the end of the day, that ends up with
us having a complete implementation of suspend2, well, Mission
Accomplished?
Hi.
On Thursday 02 February 2006 23:34, Rafael J. Wysocki wrote:
> > > First, your code introduces many changes in many parts of the kernel,
> > > so to merge it you'll have to ask many people for acceptance.
> >
> > I really must work harder to get rid of that perception. It used to be
> > the case, but isn't nowadays. Just about all of suspend2's changes are
> > new files in kernel/power and include/<arch>/suspend2.h. The remainder
> > are misc fixes, and enhancements like Christoph's todo list.
>
> Well, in your previous series of patches there are examples to the
> contrary, like the changes to kthread_create() or workqueues. They would
> require an ack from the maintainers of that code, at least.
That's not Suspend2 itself, but rather improvements to the freezer that are
logically distinct and would be useful to swsusp too. That said, if the work
you guys have done in the last couple of days gets merged, perhaps I'll drop
most of it and just do the bdev freezing instead of sys_syncing, at least to
check reliability.
> Also, you probably need some changes in the arch code. If that is so, the
> maintainers of relevant architectures should be asked.
>
> That already is "many".
No. I have a little cleaning up still to do there, but the current arch
specific patches are all: 1) adding suspend2.h; 2) old modifications that can
be cleaned up 3) the odd new routine (eg a page_is_ram function for amd64).
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Thursday 02 February 2006 22:53, Rafael J. Wysocki wrote:
> Hi,
>
> On Thursday 02 February 2006 10:38, Pavel Machek wrote:
> > > Its limitation , however, is that it requires a lot of memory for the
> > > system memory snapshot which may be impractical for systems with
> > > limited RAM, and that's where your solution may be required.
> >
> > Actually, suspend2 has similar limitation. It still needs half a
> > memory free, but it does not count caches into that as it can save
> > them separately.
>
> I didn't know that. [If that is the case, I wonder what Nigel means by
> the "whole memory image". Nigel?]
The LRU almost always easily accounts for more 50% of memory in use. Suspend2
writes LRU pages to disk, then uses those pages to store the atomic copy of
the remainder of memory. That's how I overcome the 50% problem and still
really do get a full image of memory. If the LRU is smaller than the
remainder of memory in use, we allocate extra memory if possible. If that
still doesn't give enough memory for the atomic copy, we seek to free memory
until that constraint is satisfied. If we free everything we can, and still
can't satisfy that constraint, we give up and return control to the user. In
99% of the cases, however, no freeing of memory is required and the user
really can get a full image of memory saved.
> > That means that on certain small systems (32MB RAM?), suspend2 is going
> > to have big advantage of responsivity after resume. But on the systems
> > where [u]swsusp can't suspend (6MB RAM?), suspend2 is not going to be
> > able to suspend, either. [Roughly; due to bugs and implementation
> > differences there may be some system size where one works and second one
> > does not, but they are pretty similar]
>
> Generally speaking, my perception is that suspend2 may be preferrable below
> 256 MB of RAM. Moreover there are some people who seem to prefer
> entirely kernel-based suspend, and I'm not going to develop the code
> in swap.c and disk.c any further (of course with the exception of bugfixes
> etc.). Nigel has done it already so perhaps there is a room for his code,
> too, _provided_ _that_ it is accepted.
All of the machines I regularly use have 512M+ of memory. Suspend2 is
definitely preferable on them because I've worked hard to maximise I/O
throughput. Last time I measured swsusp throughput, it was 16MB/s on my old
Omnibook. Suspend2 achieved ~25MB writing and 50MB/s reading when using LZF
compression (933 Celeron), or the 35MB/s uncompressed (the maximum throughput
that could be achieved according to tools like hdparm -t) on the same system.
With the same drive in my new laptop (amd64 M34), I get ~70MB/s read/write
(depending on cpufreq settings). My 3G P4s at work and home do about 70
(w)/110(r) MB/s. (All of this is using LZF compression).
Regards,
Nigel
> Greetings,
> Rafael
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Thursday 02 February 2006 22:48, Pekka J Enberg wrote:
> On Wednesday 01 February 2006 23:01, Pekka Enberg wrote:
> > > > +
> > > > +static inline void suspend_initialise_module_lists(void) {
> > > > + INIT_LIST_HEAD(&suspend_filters);
> > > > + INIT_LIST_HEAD(&suspend_writers);
> > > > + INIT_LIST_HEAD(&suspend_modules);
> > > > +}
> > >
> > > I couldn't find a user for this. I would imagine there's only one,
> > > though, and this should be inlined there?
>
> On Thu, 2 Feb 2006, Nigel Cunningham wrote:
> > I forgot to mention re this - yes, there's just one caller, in another
> > set of patches I'll send later (this was just the first set!). Having the
> > function to be inlined in this .h so that it's with other module specific
> > code, and then used in the caller once it has been #included, isn't that
> > the right way to do things?
>
> Sorry, I can't parse the above :-). My point was that this is
> probably called in a .c file so move the function in that file and
> introduce it whenever you introduce the caller.
I understand that. However if I do it, I separate the routine from the code it
logically belongs with. On the other hand, I do no harm by leaving it in the
header. We don't end up with multiple copies of the routine.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On Thu, 2006-02-02 at 13:27 -0800, Andrew Morton wrote:
> And having them separate like this weakens both in the area where
> the real problems are: drivers.
Which are the worst offenders, keeping in mind that ALSA was recently
fixed?
Lee
Lee Revell <[email protected]> wrote:
>
> On Thu, 2006-02-02 at 13:27 -0800, Andrew Morton wrote:
> > And having them separate like this weakens both in the area where
> > the real problems are: drivers.
>
> Which are the worst offenders, keeping in mind that ALSA was recently
> fixed?
>
I don't have that info, sorry - that was vague handwaving.
We seem to get a lot of reports of PATA drivers failing to resume correctly.
And video hardware not coming back in a sane state (lack of documentation).
On Thu, 2006-02-02 at 14:23 -0800, Andrew Morton wrote:
> Lee Revell <[email protected]> wrote:
> >
> > On Thu, 2006-02-02 at 13:27 -0800, Andrew Morton wrote:
> > > And having them separate like this weakens both in the area where
> > > the real problems are: drivers.
> >
> > Which are the worst offenders, keeping in mind that ALSA was recently
> > fixed?
> >
>
> I don't have that info, sorry - that was vague handwaving.
>
> We seem to get a lot of reports of PATA drivers failing to resume correctly.
>
> And video hardware not coming back in a sane state (lack of documentation).
>
OK.
Follow up - do we have a rough idea how bad the suspend problem is, like
approximately what % of laptops don't DTRT and just suspend when you
close the lid?
Lee
Lee Revell <[email protected]> wrote:
>
> On Thu, 2006-02-02 at 14:23 -0800, Andrew Morton wrote:
> > Lee Revell <[email protected]> wrote:
> > >
> > > On Thu, 2006-02-02 at 13:27 -0800, Andrew Morton wrote:
> > > > And having them separate like this weakens both in the area where
> > > > the real problems are: drivers.
> > >
> > > Which are the worst offenders, keeping in mind that ALSA was recently
> > > fixed?
> > >
> >
> > I don't have that info, sorry - that was vague handwaving.
> >
> > We seem to get a lot of reports of PATA drivers failing to resume correctly.
> >
> > And video hardware not coming back in a sane state (lack of documentation).
> >
>
> OK.
>
> Follow up - do we have a rough idea how bad the suspend problem is, like
> approximately what % of laptops don't DTRT and just suspend when you
> close the lid?
>
I do recall someone had some numbers on that, but I forget who it was.
David might have a feel for it?
Hi.
On Friday 03 February 2006 07:34, Lee Revell wrote:
> On Thu, 2006-02-02 at 13:27 -0800, Andrew Morton wrote:
> > And having them separate like this weakens both in the area where
> > the real problems are: drivers.
>
> Which are the worst offenders, keeping in mind that ALSA was recently
> fixed?
USB used to be a big problem, but Greg and the other USB guys are doing great
work, and it has improved a lot since 2.6.12.
The worst areas now are video drivers, particularly where DRI and/or Nvidia
are involved.
Following that there are some is frequently used hardware such as firewire and
hardware that people try to suspend less often, such as scsi. ACPI, cpufreq
and the like have accounted for a share of problems in the past, but are
generally ok now.
Hope that helps!
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi,
On Thursday 02 February 2006 22:27, Nigel Cunningham wrote:
> On Thursday 02 February 2006 23:34, Rafael J. Wysocki wrote:
> > > > First, your code introduces many changes in many parts of the kernel,
> > > > so to merge it you'll have to ask many people for acceptance.
> > >
> > > I really must work harder to get rid of that perception. It used to be
> > > the case, but isn't nowadays. Just about all of suspend2's changes are
> > > new files in kernel/power and include/<arch>/suspend2.h. The remainder
> > > are misc fixes, and enhancements like Christoph's todo list.
> >
> > Well, in your previous series of patches there are examples to the
> > contrary, like the changes to kthread_create() or workqueues. They would
> > require an ack from the maintainers of that code, at least.
>
> That's not Suspend2 itself, but rather improvements to the freezer that are
> logically distinct and would be useful to swsusp too. That said, if the work
> you guys have done in the last couple of days gets merged,
I hope so.
> perhaps I'll drop most of it and just do the bdev freezing instead of
> sys_syncing, at least to check reliability.
Well, I must admit I haven't read your bdevs-freezing patch, mostly due to
limited time, but in principle I'm not against it.
> > Also, you probably need some changes in the arch code. If that is so, the
> > maintainers of relevant architectures should be asked.
> >
> > That already is "many".
>
> No. I have a little cleaning up still to do there, but the current arch
> specific patches are all: 1) adding suspend2.h; 2) old modifications that can
> be cleaned up 3) the odd new routine (eg a page_is_ram function for amd64).
If that is so, fine. As I said before, as far as I'm concerned both solutions
can coexist as long as they don't conflict.
Greetings,
Rafael
Hi,
On Thursday 02 February 2006 22:27, Andrew Morton wrote:
> Pavel Machek <[email protected]> wrote:
> >
> > > I don't want to argue Pavel. I want to give users the best suspend to disk
> > > implementation they can get. If you want to argue, you can do so with
> >
> > I want to create best suspen that can be still merged into kernel; I
> > guess thats the difference. Anyway I believe that most of suspend
> > should be done in userspace -- most of it can. But I guess you need to
> > hear it from Linus/Andrew, so...
>
> You're unlikely to hear anything dispositive from either of us on this.
> You three guys know far more than us about suspend, so it would be silly
> for us to be making the technical decisions. When cornered, we're more
> likely to come out with general kernel platitudes such as "doing it in
> userspace:good" and "crashing the kernel:bad" and "incremental development
> with early merges:good" and "mucking up the kernel source:bad".
>
> What we hope and expect is that you'll come up with an agreed path in
> accordance with general kernel coding and development principles. Linus
> and I don't want to have to make tiebreak decisions - if we have to do
> that, the system has failed.
>
> Random thoughts:
>
> - swsusp has been a multi-year ongoing source of churn and bug reports.
> It hasn't been a big success and we have a way to go yet.
Surely. :-)
> - People seem to be doing too much development on the swsusp core and not
> enough development out where the actual problems are: drivers which don't
> suspend and resume correctly.
I haven't had any problems with drivers wrt suspend to disk recently, but
s2ram vs video is a different story. AFAICT, Pavel is working on it.
Unfortunately I can't help here, because I'm not a driver expert, so I do
what I can ie. improve the swsusp core.
Still, the driver problems are common to both swsusp and suspend2.
> - suspend2 is at a disadvantage because swsusp was merged first. If
> neither of the solutions had been merged and if we were evaluating them
> side-by-side, suspend2 would have a much better chance. This is a
> problem.
>
> - If you want my cheerfully uninformed opinion, we should toss both of
> them out and implement suspend3, which is based on the kexec/kdump
> infrastructure. There's so much duplication of intent here that it's not
> funny. And having them separate like this weakens both in the area where
> the real problems are: drivers.
Well, I started to work on swsusp, because it was in the kernel and it didn't
work on my box. Now I'm almost satisfied with how it works for me, but
I'm all for further improvements.
> - Justifying the inclusion of a feature by the appearance and usefulness
> of the end result doesn't really work in this world. There are numerous
> unmerged kernel features out there which work well and look great. But
> we will look under the hood, and that's when problems start.
>
>
> So, as promised, there's nothing useful here. What we'd most like to see
> is for Nigel to start working on in-kernel swsusp, merging up the good bits
> from suspend2 in some evolutionary incremental manner under which the
> kernel continually improves.
That is exactly what I'd like to happen.
> If, at the end of the day, that ends up with us having a complete
> implementation of suspend2, well, Mission Accomplished?
Most probably we'll end up with something else, maybe better? ;-)
Greetings,
Rafael
Hi,
On Thursday 02 February 2006 22:27, Nigel Cunningham wrote:
> On Thursday 02 February 2006 22:53, Rafael J. Wysocki wrote:
> > On Thursday 02 February 2006 10:38, Pavel Machek wrote:
> > > > Its limitation , however, is that it requires a lot of memory for the
> > > > system memory snapshot which may be impractical for systems with
> > > > limited RAM, and that's where your solution may be required.
> > >
> > > Actually, suspend2 has similar limitation. It still needs half a
> > > memory free, but it does not count caches into that as it can save
> > > them separately.
> >
> > I didn't know that. [If that is the case, I wonder what Nigel means by
> > the "whole memory image". Nigel?]
>
> The LRU almost always easily accounts for more 50% of memory in use. Suspend2
> writes LRU pages to disk, then uses those pages to store the atomic copy of
> the remainder of memory. That's how I overcome the 50% problem and still
> really do get a full image of memory. If the LRU is smaller than the
> remainder of memory in use, we allocate extra memory if possible. If that
> still doesn't give enough memory for the atomic copy, we seek to free memory
> until that constraint is satisfied. If we free everything we can, and still
> can't satisfy that constraint, we give up and return control to the user. In
> 99% of the cases, however, no freeing of memory is required and the user
> really can get a full image of memory saved.
Now that's clear to me. Thanks for the explanation.
> > > That means that on certain small systems (32MB RAM?), suspend2 is going
> > > to have big advantage of responsivity after resume. But on the systems
> > > where [u]swsusp can't suspend (6MB RAM?), suspend2 is not going to be
> > > able to suspend, either. [Roughly; due to bugs and implementation
> > > differences there may be some system size where one works and second one
> > > does not, but they are pretty similar]
> >
> > Generally speaking, my perception is that suspend2 may be preferrable below
> > 256 MB of RAM. Moreover there are some people who seem to prefer
> > entirely kernel-based suspend, and I'm not going to develop the code
> > in swap.c and disk.c any further (of course with the exception of bugfixes
> > etc.). Nigel has done it already so perhaps there is a room for his code,
> > too, _provided_ _that_ it is accepted.
>
> All of the machines I regularly use have 512M+ of memory. Suspend2 is
> definitely preferable on them because I've worked hard to maximise I/O
> throughput. Last time I measured swsusp throughput, it was 16MB/s on my old
> Omnibook. Suspend2 achieved ~25MB writing and 50MB/s reading when using LZF
> compression (933 Celeron), or the 35MB/s uncompressed (the maximum throughput
> that could be achieved according to tools like hdparm -t) on the same system.
> With the same drive in my new laptop (amd64 M34), I get ~70MB/s read/write
> (depending on cpufreq settings). My 3G P4s at work and home do about 70
> (w)/110(r) MB/s. (All of this is using LZF compression).
I was referring to the (not so far) future situation when we have compression
in the userland suspend/resume utilities. The times of writing/reading the image
will be similar to yours and IMHO it's usually possible to free 1/2 of RAM
in a box with 512+ MB of RAM at a little cost as far as the responsiveness
after resume is concerned. Thus on machines with 512+ MB of RAM
both solutions will give similar results performance-wise, but the
userland-driven suspend gives you much more flexibility wrt what you can
do with the image (eg. you can even send it over the network if need be).
On machines with less RAM suspend2 will probably be better preformance-wise,
and that may be more important than the flexibility.
Greetings,
Rafael
Hi Andrew et al.
On Friday 03 February 2006 07:27, Andrew Morton wrote:
> Pavel Machek <[email protected]> wrote:
> > > I don't want to argue Pavel. I want to give users the best suspend to
> > > disk implementation they can get. If you want to argue, you can do so
> > > with
> >
> > I want to create best suspen that can be still merged into kernel; I
> > guess thats the difference. Anyway I believe that most of suspend
> > should be done in userspace -- most of it can. But I guess you need to
> > hear it from Linus/Andrew, so...
>
> You're unlikely to hear anything dispositive from either of us on this.
> You three guys know far more than us about suspend, so it would be silly
> for us to be making the technical decisions. When cornered, we're more
> likely to come out with general kernel platitudes such as "doing it in
> userspace:good" and "crashing the kernel:bad" and "incremental development
> with early merges:good" and "mucking up the kernel source:bad".
>
> What we hope and expect is that you'll come up with an agreed path in
> accordance with general kernel coding and development principles. Linus
> and I don't want to have to make tiebreak decisions - if we have to do
> that, the system has failed.
>
> Random thoughts:
>
> - swsusp has been a multi-year ongoing source of churn and bug reports.
> It hasn't been a big success and we have a way to go yet.
>
> - People seem to be doing too much development on the swsusp core and not
> enough development out where the actual problems are: drivers which don't
> suspend and resume correctly.
>
> - suspend2 is at a disadvantage because swsusp was merged first. If
> neither of the solutions had been merged and if we were evaluating them
> side-by-side, suspend2 would have a much better chance. This is a
> problem.
>
> - If you want my cheerfully uninformed opinion, we should toss both of
> them out and implement suspend3, which is based on the kexec/kdump
> infrastructure. There's so much duplication of intent here that it's not
> funny. And having them separate like this weakens both in the area where
> the real problems are: drivers.
>
> - Justifying the inclusion of a feature by the appearance and usefulness
> of the end result doesn't really work in this world. There are numerous
> unmerged kernel features out there which work well and look great. But
> we will look under the hood, and that's when problems start.
>
>
> So, as promised, there's nothing useful here. What we'd most like to see
> is for Nigel to start working on in-kernel swsusp, merging up the good bits
> from suspend2 in some evolutionary incremental manner under which the
> kernel continually improves. If, at the end of the day, that ends up with
> us having a complete implementation of suspend2, well, Mission
> Accomplished?
Thanks for the reply. You're right. It doesn't help at all :)
Well, actually it does.
It reminds me why I started working on this in the first place. It wasn't
because I wanted to be a big shot kernel developer or the like, or have my
name in the kernel credits. It was because I wanted to use the code.
So, given that I'm perfectly willing to send Pavel patches, but he's not
willing to take them, I guess I the best thing I can do is to just let Pavel
have his way, give up on the concept of merging Suspend2 and maintain it out
of tree. When Pavel and Rafael get swsusp up to scratch, I can stop doing
that and just use their version.
Well, that's what I think at the moment. Let's see how things progress.
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Friday 03 February 2006 08:10, Rafael J. Wysocki wrote:
> I was referring to the (not so far) future situation when we have
> compression in the userland suspend/resume utilities. The times of
> writing/reading the image will be similar to yours and IMHO it's usually
> possible to free 1/2 of RAM in a box with 512+ MB of RAM at a little cost
> as far as the responsiveness after resume is concerned. Thus on machines
> with 512+ MB of RAM
> both solutions will give similar results performance-wise, but the
> userland-driven suspend gives you much more flexibility wrt what you can
> do with the image (eg. you can even send it over the network if need be).
>
> On machines with less RAM suspend2 will probably be better
> preformance-wise, and that may be more important than the flexibility.
Ok. So I bit the bullet and downloaded -mm4 to take a look at this interface
you're making, and I have a few questions:
- It seems to be hardwired to use swap, but you talk about writing to a
network image above. In Suspend2, I just bmap whatever the storage is, and
then submit bios to read and write the data. Is anything like that possible
with this interface? (Could it be extended if not?)
- Is there any way you could support doing a full image of memory with this
approach? Would you take patches?
- Does the data have to be transferred to userspace? Security and efficiency
wise, it would seem to make a lot more sense just to be telling the kernel
where to write things and let it do bio calls like I'm doing at the moment.
- In your Documentation file, you say say opening /dev/snapshot for reading is
done when suspending. Shouldn't that be open read for resume and write for
suspend?
I'm not saying I'm going to get carried away trying to port Suspend2 to
userspace. Just tentatively exploring. But if I did decide to port it, my
default position would be to seek not to drop a single feature. I hope that's
not too unreasonable!
NIgel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Quoting Nigel Cunningham <[email protected]>:
> It reminds me why I started working on this in the first place. It wasn't
> because I wanted to be a big shot kernel developer or the like, or have my
> name in the kernel credits. It was because I wanted to use the code.
And what a superb job you have done with suspend2! Kudos Nigel!
Here are the facts from my notebook suspend2 actually does work, works
reliably, is fast and pretty, none of which is true for swsusp. From my
user perspective, the refusal to merge suspend2 into mainline etc. is
just contributing to one thing - Linux not having decent suspend/resume
in vanilla tree.
I travel on the train every day and I can confidently say that I'm the
only person there with a Linux based notebook. Everyone else is having
Windows or an occasional Mac. These people *never* have to worry about
suspending and resuming - it just works for them. That's because
Microsoft and Apple decided this was important many, many years ago.
Unless mainline kernel folks decide to give people something that works
and works reliably, this thing will drag on for many more years, I'm
afraid. Ah well, as long as you keep the great job releasing suspend2
for the up-to-date kernels, at least one more Linux notebook will be
able to suspend/resume properly.
Bottom line: With your code, my machine works. Without it, it doesn't.
--
Bojan
Bojan Smojver <[email protected]> wrote:
>
> Bottom line: With your code, my machine works. Without it, it doesn't.
This leaves us in rather awkward position. You see, there will be other
people whose machines don't work with suspend2 but which do work with
swsusp. And other people who prefer swsusp for other reasons.
It'd help if we knew _why_ your machine doesn't work with swsusp so we can
fix it. Futhermore it'd help if we knew specifically what you prefer about
suspend2 so we can understand what more needs to be done, and how we should
do it.
On Thu, Feb 02, 2006 at 09:51:48PM +0100, Pavel Machek wrote:
> Well, Olivier said I'm turning kernel into Hurd.
You're far from the only one. There is currently a real fad into
putting as many things as possible (or not) in userspace without
seemingly thinking about things like security, long term
maintainability, usability or even compatiblity between kernel
versions and userspace versions.
> So he instead
> advocates merging 10 000 lines of code (+7500, contains new
> compression algorithm and new plugin architecture). I'd like to add
> interface to userland (+300) and remove swap writing (long term,
> -1000).
I don't actually advocate suspend2. I indeed have not looked at the
patches at that point. I do find it extremely annoying that instead
of trying to make what exists reliable, for instance what are the
rules irq grabbing/release at that point, and adding infrastructure
for what's missing for having real reliability, f.i. communication
with fb/drm to handle the screen power switch, you decide to go and
move things into userspace which is going to increase the reliability
problems immensely. I don't even want to think about the interactions
between freezing the userspace memory pages and running some processes
which may malloc/mmap at the same time.
OG.
Hi again.
On Friday 03 February 2006 11:18, Andrew Morton wrote:
> Bojan Smojver <[email protected]> wrote:
> > Bottom line: With your code, my machine works. Without it, it doesn't.
>
> This leaves us in rather awkward position. You see, there will be other
> people whose machines don't work with suspend2 but which do work with
> swsusp. And other people who prefer swsusp for other reasons.
>
> It'd help if we knew _why_ your machine doesn't work with swsusp so we can
> fix it. Futhermore it'd help if we knew specifically what you prefer about
> suspend2 so we can understand what more needs to be done, and how we should
> do it.
As much as I appreciate Bojan's comments, I want to ask the same question -
when it comes to driver model invocations and the method of restoring the
original kernel data, swsusp and Suspend2 work in almost exactly the same
way, so if one works for someone, the other should too and vice versa.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Quoting Andrew Morton <[email protected]>:
> This leaves us in rather awkward position. You see, there will be other
> people whose machines don't work with suspend2 but which do work with
> swsusp. And other people who prefer swsusp for other reasons.
From what I can see on suspend2 development list, Nigel regularly
addresses people's problems with his code, which then results in
working systems. Most times when people see problems with suspend2, it
is the drivers that can't do suspend that are the root cause (at least
that seems to be the pattern on the suspend2 mailing list).
The only way for a much broader community to experience and test
suspend2 is to put it in the mainline kernel. I'm not sure why that is
such a problem...
> It'd help if we knew _why_ your machine doesn't work with swsusp so we can
> fix it. Futhermore it'd help if we knew specifically what you prefer about
> suspend2 so we can understand what more needs to be done, and how we should
> do it.
Here is what I prefer in suspend2:
- it works (i.e. I have compiled it for at least 20 different Rawhide
kernels and it always suspended/resumed properly)
- it is reliable (e.g. I have suspended/resumed mid kernel compile -
actually, kernel RPM build, which included compile - many times,
without any ill effect)
- it is fast (i.e. even on my crappy old HP ZE4201
[http://www.rexursive.com/articles/linuxonhpze4201.html], it writes all
of 700+ MB of RAM to disk just as fast or faster than swsusp).
- it looks nice (both text and GUI interface supported)
- it leaves the system responsive on resume (kinda nice to come back to
X and "Just Use it")
- it suspends to both swap and file (I personally use swap, but many
people on the list use file)
Just today, I tried the most recent Rawhide kernel (based on
2.6.16-rc1-git5) with swsusp and for the first time *ever* it actually
returned X to its original state (I was so excited, I even notified
people on suspend2 development list about it). But, on second
suspend/resume, it promptly locked up my system. Before, it would
simply lock up. So, if swsusp can be made to actually work, be
reliable, look nice and be responsive on resume, I'm all for it. I will
miss Nigel's excellent support though, but I'm sure he deserves a break
:-)
--
Bojan
On Thu, Feb 02, 2006 at 05:29:40PM -0500, Lee Revell wrote:
> Follow up - do we have a rough idea how bad the suspend problem is, like
> approximately what % of laptops don't DTRT and just suspend when you
> close the lid?
None of the Dells we use at work (various models) handle suspend (both
ram and disk) reliably. Got everything from not resuming when pushing
the button (PWRF not giving an ACPI event while PWRC does), screen not
coming back (as usual), system not coming back the second time (go
figure) or resume eating up / from time to time. At that point people
there are buying Macs.
I'm going to get a sacrificial (but modern) dell laptop in a month or
two. I'll try to make things actually reliable on that one, including
video. I don't have great hopes though.
'course the current state of the drm/fb interaction is yet another can
of worms, one in a good way of being solved though.
OG.
[1] Reverse engineering is one of my hobbies
Hi Oliver.
On Friday 03 February 2006 11:48, Olivier Galibert wrote:
> On Thu, Feb 02, 2006 at 05:29:40PM -0500, Lee Revell wrote:
> > Follow up - do we have a rough idea how bad the suspend problem is, like
> > approximately what % of laptops don't DTRT and just suspend when you
> > close the lid?
>
> None of the Dells we use at work (various models) handle suspend (both
> ram and disk) reliably. Got everything from not resuming when pushing
> the button (PWRF not giving an ACPI event while PWRC does), screen not
> coming back (as usual), system not coming back the second time (go
> figure) or resume eating up / from time to time. At that point people
> there are buying Macs.
Not coming back the second time usually means it staggers through the first
dazed and confused, but not badly enough so that you notice. The second
attempt kills it. In this case, I'd go looking for something that plays up
after the first resume. You might also try some of the hints on the suspend2
web site, such as trying from init S with minimal modules loaded. (If that
works, you know it's something loaded later in the boot process that messes
things up).
> I'm going to get a sacrificial (but modern) dell laptop in a month or
> two. I'll try to make things actually reliable on that one, including
> video. I don't have great hopes though.
If you can't get it to go, try the suspend2 mailing list. I try to be as
helpful as I can, and there are tons of users on there with good suggestions
and experience you can make use of as well.
> 'course the current state of the drm/fb interaction is yet another can
> of worms, one in a good way of being solved though.
Yes. You'll have much better success without DRI in the picture.
Regards,
Nigel
> OG.
>
> [1] Reverse engineering is one of my hobbies
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi,
On Friday 03 February 2006 01:20, Nigel Cunningham wrote:
> On Friday 03 February 2006 08:10, Rafael J. Wysocki wrote:
> > I was referring to the (not so far) future situation when we have
> > compression in the userland suspend/resume utilities. The times of
> > writing/reading the image will be similar to yours and IMHO it's usually
> > possible to free 1/2 of RAM in a box with 512+ MB of RAM at a little cost
> > as far as the responsiveness after resume is concerned. Thus on machines
> > with 512+ MB of RAM
> > both solutions will give similar results performance-wise, but the
> > userland-driven suspend gives you much more flexibility wrt what you can
> > do with the image (eg. you can even send it over the network if need be).
> >
> > On machines with less RAM suspend2 will probably be better
> > preformance-wise, and that may be more important than the flexibility.
>
> Ok. So I bit the bullet and downloaded -mm4 to take a look at this interface
> you're making, and I have a few questions:
>
> - It seems to be hardwired to use swap, but you talk about writing to a
> network image above. In Suspend2, I just bmap whatever the storage is, and
> then submit bios to read and write the data. Is anything like that possible
> with this interface? (Could it be extended if not?)
The swap partition was easy. :-) However, there is the bmap() call that
userspace processes can use, so it seems to be possible. [BTW, the network
is easy too, because it desn't require us to tamper with disks while
suspended.]
> - Is there any way you could support doing a full image of memory with this
> approach?
I'm not sure, but I think that's possible. For now I don't see major
obstacles, but honestly I'll have to read your code (and understand it)
to answer this question responsibly.
> Would you take patches?
Well, the code in question is already in the kernel (in -mm, but this doesn't
matter here) and I'm not the maintainer of it, so I can't answer this
question directly. However, if you asked me whether I would _support_ any
patches, I would say I had never opposed or supported a patch whithout trying
to understand it.
When I think I understand the patch, I try to value it, and I have two rules
here:
1) The released code should always be functional. [So I never submit
untested patches without saying explicitly that they are untested and if I
replace some code A with alternative code B, I do my best to ensure it
won't break any existing setups.]
2) The software with this patch applied must be such that I would like to run
it on my computer. [If I wouldn't, there's no chance I'll support it.]
> - Does the data have to be transferred to userspace? Security and efficiency
> wise, it would seem to make a lot more sense just to be telling the kernel
> where to write things and let it do bio calls like I'm doing at the moment.
First, there's a difference between efficiency and performance.
For example, the kernel already contains the code for writing data to the disk
or partition you are using for suspend. By using bio directly to write to it
you're duplicating the functionality of that code which is _inefficient_,
although this need not be related to performance. Worse yet, if some
optimizations go to this code, you won't have them unless you notice
and implement them once again.
Similar observation applies to enryption and compression: There are libraries
for encryption and compression that contain lots of different algorithms,
so why should we try to duplicate that code? It is more efficient to _use_
it, which can be done easily in the user space.
This may hurt performance a bit, but usually not so far that anyone will
notice. [Actually on my box the suspending and resuming userland
utilities I use for testing perform the I/O-related operations _faster_
than the built-in swsusp code, although they seemingly do the same
things.]
Second, as far as the security is concerned, the only problem I see is that a
malicious attacker may be able to read unencrypted suspend image from the
system or submit his own specially crafted image which would require
root-equivalent access anyway. However to prevent this you can set whatever
paranoid permissions you desire on /dev/snapshot and implement your
suspending utility as a daemon running in a privileged security ring (the
resume is run from and initrd anyway).
The biggest advantage of the userland-based approach I see is that there
may be _many_ implementations of the suspending and resuming tools
and they will not conflict. For example, if Distributor X needs an exotic feature
Y wrt suspend (various vendor-specific eye-candies come to mind or
transferring the image over a network), he can implement it in his userland
tools without modifying the kernel. Similarly, if Vendor V wants to use paranoid
encryption algorithm Z to encrypt the image, she can do that _herself_ in the
user space.
We only need to provide reference tools and we won't be asked to implement
every feature that people may want in the kernel.
> - In your Documentation file, you say say opening /dev/snapshot for reading is
> done when suspending. Shouldn't that be open read for resume and write for
> suspend?
No. During suspend the image is read from the kernel and saved by a userland
tool and analogously during resume.
> I'm not saying I'm going to get carried away trying to port Suspend2 to
> userspace. Just tentatively exploring. But if I did decide to port it, my
> default position would be to seek not to drop a single feature. I hope that's
> not too unreasonable!
That's fine. I think we have the same goal which is a reasonable set of
features available to the users.
[Heh, that looks like a good starter for the userland suspend FAQ. Perhaps
I should save this message. ;-)]
Greetings,
Rafael
Hi,
On Friday 03 February 2006 02:42, Bojan Smojver wrote:
> Quoting Andrew Morton <[email protected]>:
>
> > This leaves us in rather awkward position. You see, there will be other
> > people whose machines don't work with suspend2 but which do work with
> > swsusp. And other people who prefer swsusp for other reasons.
>
> From what I can see on suspend2 development list, Nigel regularly
> addresses people's problems with his code, which then results in
> working systems. Most times when people see problems with suspend2, it
> is the drivers that can't do suspend that are the root cause (at least
> that seems to be the pattern on the suspend2 mailing list).
>
> The only way for a much broader community to experience and test
> suspend2 is to put it in the mainline kernel. I'm not sure why that is
> such a problem...
>
> > It'd help if we knew _why_ your machine doesn't work with swsusp so we can
> > fix it. Futhermore it'd help if we knew specifically what you prefer about
> > suspend2 so we can understand what more needs to be done, and how we should
> > do it.
>
> Here is what I prefer in suspend2:
>
> - it works (i.e. I have compiled it for at least 20 different Rawhide
> kernels and it always suspended/resumed properly)
>
> - it is reliable (e.g. I have suspended/resumed mid kernel compile -
> actually, kernel RPM build, which included compile - many times,
> without any ill effect)
>
> - it is fast (i.e. even on my crappy old HP ZE4201
> [http://www.rexursive.com/articles/linuxonhpze4201.html], it writes all
> of 700+ MB of RAM to disk just as fast or faster than swsusp).
>
> - it looks nice (both text and GUI interface supported)
>
> - it leaves the system responsive on resume (kinda nice to come back to
> X and "Just Use it")
>
> - it suspends to both swap and file (I personally use swap, but many
> people on the list use file)
>
> Just today, I tried the most recent Rawhide kernel (based on
> 2.6.16-rc1-git5) with swsusp and for the first time *ever* it actually
> returned X to its original state (I was so excited, I even notified
> people on suspend2 development list about it). But, on second
> suspend/resume, it promptly locked up my system.
Well, it would help if you said in which stage of suspend/resume
it actually locked up the system.
Anyway, we are working on fixing these problems right now,
so maybe you'd like to test some patches?
> Before, it would simply lock up. So, if swsusp can be made to actually work,
> be reliable, look nice and be responsive on resume, I'm all for it.
I think it can be, hopefully with Nigel's help.
> I will miss Nigel's excellent support though, but I'm sure he deserves a break
> :-)
I'm definitely interested in resolving your problems with swsusp, so could
you please send me a boot log from your box? Also, if you are able to
get a serial console or net console output from it during suspend/resume,
especially in the failing case, that would help a lot. [Please do not litter
the list with that, though.]
Greetings,
Rafael
Lee Revell <[email protected]> wrote:
> Follow up - do we have a rough idea how bad the suspend problem is, like
> approximately what % of laptops don't DTRT and just suspend when you
> close the lid?
It's arguable whether "just suspending when you close the lid" is
actually DTRT, but if you want "how many x86 laptops can we successfully
suspend and resume" then the number is between 80-90% for RAM and a
little more than that for disk (numbers based on Ubuntu, other
distributions don't have as much infrastructure for this right now).
This is based on doing hacky things like unloading all the network and
USB drivers before suspend, but by and large the driver situation is
much improved. The single biggest problem is video reinitialisation, and
that can't be solved in-kernel.
Based on actual hard, shipping evidence - swsusp works sufficiently well
that throwing it out and replacing it with a different implemenation is
entirely unnecessary. The two big advantages that suspend2 brings us are
1) Improved speed (an entirely fair objection to swsusp)
2) Graphical bling (and I think doing that in the kernel is pretty
insane)
Pavel's proposed plan brings us both of those without massive kernel
changes, so I'm really quite tempted to go with that. From a
distribution standpoint, integrating it is very straightforward.
(By and large, the biggest problem is repeated kernel regressions that
hit suspend in bizarre ways. This doesn't get picked up on quickly
because almost nobody is using this code, because "everyone knows" it
doesn't work. Except it /does/. What we need is for distributions to
actually work together on this, rather than everyone trying to fix the
same problems independently, each coming up with different solutions and
the world generally being a miserable place)
--
Matthew Garrett | [email protected]
Matthew Garrett <[email protected]> wrote:
>
> (By and large, the biggest problem is repeated kernel regressions that
> hit suspend in bizarre ways. This doesn't get picked up on quickly
> because almost nobody is using this code, because "everyone knows" it
> doesn't work. Except it /does/. What we need is for distributions to
> actually work together on this, rather than everyone trying to fix the
> same problems independently, each coming up with different solutions and
> the world generally being a miserable place)
Is it still the case that swsusp requries that the disk drivers be
statically linked into vmlinux?
If so, I'd have thought that this was quite a problem for distros,
although I have a vague feeling that RH worked around it in some manner.
On P? 03-02-06 02:18:39, Olivier Galibert wrote:
> On Thu, Feb 02, 2006 at 09:51:48PM +0100, Pavel Machek wrote:
> > So he instead
> > advocates merging 10 000 lines of code (+7500, contains new
> > compression algorithm and new plugin architecture). I'd like to add
> > interface to userland (+300) and remove swap writing (long term,
> > -1000).
>
> I don't actually advocate suspend2. I indeed have not looked at the
> patches at that point. I do find it extremely annoying that instead
> of trying to make what exists reliable, for instance what are the
I'm trying to make what exists reliable, but I'm under some pressure
to allow things like progress bars. And for progress bars (etc) to be
feasible, it needs to be in userspace.
> rules irq grabbing/release at that point, and adding infrastructure
> for what's missing for having real reliability, f.i. communication
> with fb/drm to handle the screen power switch, you decide to go and
> move things into userspace which is going to increase the reliability
> problems immensely. I don't even want to think about the interactions
> between freezing the userspace memory pages and running some processes
> which may malloc/mmap at the same time.
There are none. userspace helper is mlocked, and rest of userspace is
stopped.
Pavel
--
Thanks, Sharp!
Andrew Morton <[email protected]> wrote:
> Is it still the case that swsusp requries that the disk drivers be
> statically linked into vmlinux?
No, I submitted a patch for that that went into 2.6.13. In
initrd/initramfs, load the controller modules and then echo the
major:minor of the suspend device into /sys/power/resume. As long as
this is done before any filesystems are mounted, it works fine.
(Yes, it gives you the ability to shoot yourself in the foot, but then
so does the rest of the kernel...)
--
Matthew Garrett | [email protected]
On Čt 02-02-06 14:23:23, Andrew Morton wrote:
> Lee Revell <[email protected]> wrote:
> >
> > On Thu, 2006-02-02 at 13:27 -0800, Andrew Morton wrote:
> > > And having them separate like this weakens both in the area where
> > > the real problems are: drivers.
> >
> > Which are the worst offenders, keeping in mind that ALSA was recently
> > fixed?
> >
>
> I don't have that info, sorry - that was vague handwaving.
>
> We seem to get a lot of reports of PATA drivers failing to resume correctly.
>
> And video hardware not coming back in a sane state (lack of documentation).
Video problems seem to be broken for suspend2ram, not swsusp.
Not that we don't have swsusp drivers problems, but they tend to be
randomly, all over the map, mostly over drivers I never heard about.
suspend2ram is different fish, video and ATA are real problems
there. At least there are solutions on ATA being worked on.
Pavel
--
Thanks, Sharp!
On P? 03-02-06 02:48:46, Olivier Galibert wrote:
> On Thu, Feb 02, 2006 at 05:29:40PM -0500, Lee Revell wrote:
> > Follow up - do we have a rough idea how bad the suspend problem is, like
> > approximately what % of laptops don't DTRT and just suspend when you
> > close the lid?
>
> None of the Dells we use at work (various models) handle suspend (both
> ram and disk) reliably. Got everything from not resuming when pushing
> the button (PWRF not giving an ACPI event while PWRC does), screen not
> coming back (as usual), system not coming back the second time (go
> figure) or resume eating up / from time to time. At that point people
> there are buying Macs.
Please debug suspend2disk first, and talk about them separately. They
are really different. If you have problem with suspend2disk, it should
be easy to solve it (or at least point you at problematic module). I
would not want to promise that for suspend2ram (we can usually fix
that, too, but). Please keep them separate.
Pavel
--
Thanks, Sharp!
On P? 03-02-06 09:49:33, Matthew Garrett wrote:
> Lee Revell <[email protected]> wrote:
>
> > Follow up - do we have a rough idea how bad the suspend problem is, like
> > approximately what % of laptops don't DTRT and just suspend when you
> > close the lid?
>
> It's arguable whether "just suspending when you close the lid" is
> actually DTRT, but if you want "how many x86 laptops can we
> successfully
:-).
> suspend and resume" then the number is between 80-90% for RAM and a
> little more than that for disk (numbers based on Ubuntu, other
> distributions don't have as much infrastructure for this right now).
> This is based on doing hacky things like unloading all the network and
> USB drivers before suspend, but by and large the driver situation is
> much improved. The single biggest problem is video reinitialisation, and
> that can't be solved in-kernel.
...and Ubuntu has vbetool solution which seems to work on 90% of all
notebooks, nice. Which big whitelist that basically says it all
works. Thanks for doing this work.
> (By and large, the biggest problem is repeated kernel regressions that
> hit suspend in bizarre ways. This doesn't get picked up on quickly
> because almost nobody is using this code, because "everyone knows" it
> doesn't work. Except it /does/. What we need is for distributions to
> actually work together on this, rather than everyone trying to fix the
> same problems independently, each coming up with different solutions and
> the world generally being a miserable place)
Perhaps we should force suspend/resume cycle at one of 10 boots :-).
Actually if you want to very quickly test if your changes did not
break swsusp, it should be enough to do
swapoff -a; echo -n disk > /sys/power/state
. Your system will do half of system suspend, immediately followed by
resume.
Pavel
--
Thanks, Sharp!
On Čt 02-02-06 13:27:08, Andrew Morton wrote:
> Pavel Machek <[email protected]> wrote:
>
> Random thoughts:
>
> - swsusp has been a multi-year ongoing source of churn and bug reports.
> It hasn't been a big success and we have a way to go yet.
You don't get the success reports, only bug reports. It tends to work
these days. I don't get success reports, too, but I'm not flooded with
bugreports for distribution, either. (And actually see people using
suspend2/swsusp).
> - People seem to be doing too much development on the swsusp core and not
> enough development out where the actual problems are: drivers which don't
> suspend and resume correctly.
We only started developing swsusp core again at 11/2005. Problem with
drivers is that I mostly do not have affected hardware. [Okay, there
are some problems with Core Duo I can reproduce here, smp-only, but
the machine is flakey, anyway, so it will take some time.]
> - If you want my cheerfully uninformed opinion, we should toss both of
> them out and implement suspend3, which is based on the kexec/kdump
> infrastructure. There's so much duplication of intent here that it's not
> funny. And having them separate like this weakens both in the area where
> the real problems are: drivers.
I thought about it (at around 11/2005), but loosing 8+ MB of ram,
permanently, is perhaps too big price to pay?
Pavel
--
Thanks, Sharp!
Hi!
> > Video problems seem to be broken for suspend2ram, not swsusp.
> >
> > Not that we don't have swsusp drivers problems, but they tend to be
> > randomly, all over the map, mostly over drivers I never heard about.
> >
> > suspend2ram is different fish, video and ATA are real problems
> > there. At least there are solutions on ATA being worked on.
>
> What PATA problems are you talking about?
>
> In kernel bugzilla there are 2 bugs related to suspend/resume:
>
> * #5257 for 2.6.13.1 (seem to be fixed in 2.6.15.2)
> * #5673 for 2.6.14.3 (not enough information to start debugging)
>
> and I don't recall any problems being reported to linux-ide ML
> or linux-kernel ML recently.
We were not calling some ACPI methods to awake IDE correctly. It did
not properly work with disk passwords or something like that.
...ahha, have it (should be reachable from outside...):
https://bugzilla.novell.com/show_bug.cgi?id=145591
(and linked:
http://bugzilla.kernel.org/show_bug.cgi?id=2039 and
http://bugzilla.kernel.org/show_bug.cgi?id=5604
)
> Most bugreports I've seen was caused by:
> * using ide-generic instead of proper host driver
> (no wonder that it fails)
> * playing with hdparm when not needed (don't do it)
>
> Also IIRC SATA suspend/resume support was merged into
> mainline (?) so things should work better now.
I think SATA had similar problems with ACPI methods. Patches for SATA
seem to be in better shape in PATA side, but I don't think they are in.
But I do not have affected hardware here...
Pavel
--
Thanks, Sharp!
Hi!
> > So, as promised, there's nothing useful here. What we'd most like to see
> > is for Nigel to start working on in-kernel swsusp, merging up the good bits
> > from suspend2 in some evolutionary incremental manner under which the
> > kernel continually improves. If, at the end of the day, that ends up with
> > us having a complete implementation of suspend2, well, Mission
> > Accomplished?
>
> Thanks for the reply. You're right. It doesn't help at all :)
>
> Well, actually it does.
>
> It reminds me why I started working on this in the first place. It wasn't
> because I wanted to be a big shot kernel developer or the like, or have my
> name in the kernel credits. It was because I wanted to use the code.
>
> So, given that I'm perfectly willing to send Pavel patches, but he's not
> willing to take them, I guess I the best thing I can do is to just let Pavel
> have his way, give up on the concept of merging Suspend2 and maintain it out
> of tree. When Pavel and Rafael get swsusp up to scratch, I can stop doing
> that and just use their version.
[Pavel is willing to take patches, as his cooperation with Rafael
shows, but is scared by both big patches and series of 10 small
patches he does not understand. He likes patches removing code.]
Pavel
--
Thanks, Sharp!
Hi!
Just for the record.
> Here is what I prefer in suspend2:
>
> - it works (i.e. I have compiled it for at least 20 different Rawhide
> kernels and it always suspended/resumed properly)
>
> - it is reliable (e.g. I have suspended/resumed mid kernel compile -
> actually, kernel RPM build, which included compile - many times,
> without any ill effect)
Rafael has test patch for this one.
> - it is fast (i.e. even on my crappy old HP ZE4201
> [http://www.rexursive.com/articles/linuxonhpze4201.html], it writes all
> of 700+ MB of RAM to disk just as fast or faster than swsusp).
Help us with userland parts of uswsusp, pretty please?
> - it looks nice (both text and GUI interface supported)
Planned for userland parts.
> - it leaves the system responsive on resume (kinda nice to come back to
> X and "Just Use it")
Merged in latest mainline.
> - it suspends to both swap and file (I personally use swap, but many
> people on the list use file)
Doable in userland parts; not sure with someone plans it.
> Just today, I tried the most recent Rawhide kernel (based on
> 2.6.16-rc1-git5) with swsusp and for the first time *ever* it actually
> returned X to its original state (I was so excited, I even notified
> people on suspend2 development list about it). But, on second
> suspend/resume, it promptly locked up my system. Before, it would
> simply lock up. So, if swsusp can be made to actually work, be
> reliable, look nice and be responsive on resume, I'm all for it. I will
> miss Nigel's excellent support though, but I'm sure he deserves a break
> :-)
Can you do usual "try again with minimum drivers" debugging?
Pavel
--
Thanks, Sharp!
On P? 03-02-06 10:20:42, Nigel Cunningham wrote:
> Hi.
>
> On Friday 03 February 2006 08:10, Rafael J. Wysocki wrote:
> > On machines with less RAM suspend2 will probably be better
> > preformance-wise, and that may be more important than the flexibility.
>
> Ok. So I bit the bullet and downloaded -mm4 to take a look at this interface
> you're making, and I have a few questions:
Great, thanks.
> - It seems to be hardwired to use swap, but you talk about writing to a
> network image above. In Suspend2, I just bmap whatever the storage is, and
> then submit bios to read and write the data. Is anything like that possible
> with this interface? (Could it be extended if not?)
No, it is not hardwired. There's special swap support, but you do not
need to use it.
> - Is there any way you could support doing a full image of memory with this
> approach? Would you take patches?
Doing full image is certainly possible; it is not important if kernel
does the writing or userspace does it. Taking patches definitely
depends how they'd look like...
> - Does the data have to be transferred to userspace? Security and efficiency
> wise, it would seem to make a lot more sense just to be telling the kernel
> where to write things and let it do bio calls like I'm doing at the
> moment.
As far as I can see, transfering data to userspace and back does not
really cost much:
pavel@amd:~$ time head -c $[1024*1024*1024] < /dev/zero > /dev/null
0.16user 0.27system 0.43 (0m0.439s) elapsed 100.00%CPU
...2000MB/sec is the limit (thinkpad x32).
Pavel
--
Thanks, Sharp!
On 2/3/06, Pavel Machek <[email protected]> wrote:
> Hi!
>
> > > Video problems seem to be broken for suspend2ram, not swsusp.
> > >
> > > Not that we don't have swsusp drivers problems, but they tend to be
> > > randomly, all over the map, mostly over drivers I never heard about.
> > >
> > > suspend2ram is different fish, video and ATA are real problems
> > > there. At least there are solutions on ATA being worked on.
> >
> > What PATA problems are you talking about?
> >
> > In kernel bugzilla there are 2 bugs related to suspend/resume:
> >
> > * #5257 for 2.6.13.1 (seem to be fixed in 2.6.15.2)
> > * #5673 for 2.6.14.3 (not enough information to start debugging)
> >
> > and I don't recall any problems being reported to linux-ide ML
> > or linux-kernel ML recently.
>
> We were not calling some ACPI methods to awake IDE correctly. It did
> not properly work with disk passwords or something like that.
Ah, ACPI support, it is being worked on but ATA ACPI should be
used as last resort. Why? We want IDE/libata drivers to have
correct knowledge about state of controller and devices.
There are specific cases when ACPI support is required (WRT disk
passwords we can and should support this without need for ACPI)
but most of systems should work just fine without it. Also ACPI
support can just hide bugs in core code and host drivers which still
needs to be fixed (which i.e. happened for VIA IDE bug)...
> ...ahha, have it (should be reachable from outside...):
>
> https://bugzilla.novell.com/show_bug.cgi?id=145591
Jens' question is quite important here.
> (and linked:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=2039 and
VIA IDE driver had bug in tuning code which prevented
resume from working, it was fixed ages ago.
[ commented into bug entry with request for retesting
with latest kernel ]
> http://bugzilla.kernel.org/show_bug.cgi?id=5604
ide-generic is being used instead of piix (sigh)
Any other bugreports?
While at it let me explain some confusion which I've seen
cut'n'pasted into three bugreports (RedHat bugzilla, Ubuntu
bugzilla and kernel bugzilla):
"Linux currently has no real support for setting up IDE interfaces
on resume. Some machines are kind enough to set the IDE
interface up themselves, but on others we're doomed to failure."
This is untrue as Linux has support for setting IDE controller
and drives. It was added by Benjamin Herrenschmidt in late
2.5.x or early 2.6.x (I don't remember exact kernel version).
> )
>
> > Most bugreports I've seen was caused by:
> > * using ide-generic instead of proper host driver
> > (no wonder that it fails)
> > * playing with hdparm when not needed (don't do it)
> >
> > Also IIRC SATA suspend/resume support was merged into
> > mainline (?) so things should work better now.
>
> I think SATA had similar problems with ACPI methods. Patches for SATA
> seem to be in better shape in PATA side, but I don't think they are in.
They are in mainline, maybe in Jeff's git tree... still the same
comments about ACPI support not being "Holy Grail" for fixing
all ATA suspend/resume problems apply...
More general request to ACPI and PM folks - if you get bugreports
which clearly indicate that [P,S]ATA drivers to blame please narrowing
it down a bit with help of bugreporter and feel free to:
* ask on linux-ide ML about the problem
* add "me" to cc: for the bug (or asign "me" as owner)
I can't promise fixing them all but leaving bugs as they are
without _informing_ and _working_ with ATA developers is clearly
not going to help...
Thanks,
Bartlomiej
Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> This is untrue as Linux has support for setting IDE controller
> and drives. It was added by Benjamin Herrenschmidt in late
> 2.5.x or early 2.6.x (I don't remember exact kernel version).
In generic_ide_resume, rqpm.pm_step gets set to
ide_pm_state_start_resume and ide_do_drive_cmd gets called. This ends up
being passed through to start_request. start_request waits for the BSY
bit to go away. On the affected hardware I've seen, this never happens
unless the ACPI calls are made. As far as I can tell, there's nothing in
the current driver code that does anything to make sure that the bus is
in a state to accept commands at this point - the pci drivers don't (for
the most part) seem to have any resume methods. Calling the ACPI _STM
method before attempting to do this magically makes everything work.
--
Matthew Garrett | [email protected]
On Fri, Feb 03, 2006 at 11:41:29AM +0100, Pavel Machek wrote:
> > I don't even want to think about the interactions
> > between freezing the userspace memory pages and running some processes
> > which may malloc/mmap at the same time.
>
> There are none. userspace helper is mlocked, and rest of userspace is
> stopped.
Unless the userspace code is as tight as mission-critical RT code, I
don't see how that can work reliably. Some problems I see:
- What happens if the helper faults in new pages, changes its brk or
mmaps things? Can we actually swap at that point? mlocking takes
care of the fault in, not of the rest.
- What happens if the helper reads files? Where will the pages with
the file data be put? Are we saving the dcache in the image, and if
yes which state of the dcache?
- What happens if the helper writes files? What state are we saving,
before starting the helper or after? Will the fs be in a coherent
state after resume?
- What about IPC? What if for instance the helper tries to contact
HAL to get some system information?
And if you decide on rules on what the userspace can and can't do, how
do you plan to enforce them? We have filesystems on the line there,
you don't want them destroyed at resume because the latest version of
kdome-resume-progress-bar thought it was cool to generate an picture
of the desktop at suspend time to show at resume.
The idea of trying to save a state that can be modified dynamically
while you're saving in unpredictable ways makes me very, very afraid.
At least when you're in the kernel you can have complete control over
the machine when needed.
OG.
On 2/3/06, Matthew Garrett <[email protected]> wrote:
> Bartlomiej Zolnierkiewicz <[email protected]> wrote:
>
> > This is untrue as Linux has support for setting IDE controller
> > and drives. It was added by Benjamin Herrenschmidt in late
> > 2.5.x or early 2.6.x (I don't remember exact kernel version).
>
> In generic_ide_resume, rqpm.pm_step gets set to
> ide_pm_state_start_resume and ide_do_drive_cmd gets called. This ends up
> being passed through to start_request. start_request waits for the BSY
> bit to go away. On the affected hardware I've seen, this never happens
> unless the ACPI calls are made. As far as I can tell, there's nothing in
> the current driver code that does anything to make sure that the bus is
> in a state to accept commands at this point - the pci drivers don't (for
> the most part) seem to have any resume methods. Calling the ACPI _STM
> method before attempting to do this magically makes everything work.
I don't see anything that prevents addition of ->suspend and ->resume
for IDE PCI host drivers (not IDE core issue) if some special sequence
is needed.
I see that we may be doing PIO/DMA setup too late (IDE core issue)
for some controllers.
Could you fill a bug at kernel bugzilla with data as much data about
affected hardware as possible (dmesg, kernel config, lspci -vvv -xxx
before susped and if possible PCI configuration dumped from kernel
after suspend)?
What is the current state of IDE ACPI patches?
Were the issues raised on linux-ide addressed?
Thanks,
Bartlomiej
On Fri, Feb 03, 2006 at 02:23:05AM -0800, Andrew Morton wrote:
> Matthew Garrett <[email protected]> wrote:
> >
> > (By and large, the biggest problem is repeated kernel regressions that
> > hit suspend in bizarre ways. This doesn't get picked up on quickly
> > because almost nobody is using this code, because "everyone knows" it
> > doesn't work. Except it /does/. What we need is for distributions to
> > actually work together on this, rather than everyone trying to fix the
> > same problems independently, each coming up with different solutions and
> > the world generally being a miserable place)
>
> Is it still the case that swsusp requries that the disk drivers be
> statically linked into vmlinux?
>
> If so, I'd have thought that this was quite a problem for distros,
> although I have a vague feeling that RH worked around it in some manner.
We do it all in the initrd, before any filesystems are touched.
Dave
On Fri, 3 Feb 2006, Bartlomiej Zolnierkiewicz wrote:
> On 2/3/06, Matthew Garrett <[email protected]> wrote:
> > Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> >
> > > This is untrue as Linux has support for setting IDE controller
> > > and drives. It was added by Benjamin Herrenschmidt in late
> > > 2.5.x or early 2.6.x (I don't remember exact kernel version).
> >
> > In generic_ide_resume, rqpm.pm_step gets set to
> > ide_pm_state_start_resume and ide_do_drive_cmd gets called. This ends up
> > being passed through to start_request. start_request waits for the BSY
> > bit to go away. On the affected hardware I've seen, this never happens
> > unless the ACPI calls are made. As far as I can tell, there's nothing in
> > the current driver code that does anything to make sure that the bus is
> > in a state to accept commands at this point - the pci drivers don't (for
> > the most part) seem to have any resume methods. Calling the ACPI _STM
> > method before attempting to do this magically makes everything work.
>
> I don't see anything that prevents addition of ->suspend and ->resume
> for IDE PCI host drivers (not IDE core issue) if some special sequence
> is needed.
>
> I see that we may be doing PIO/DMA setup too late (IDE core issue)
> for some controllers.
>
> Could you fill a bug at kernel bugzilla with data as much data about
> affected hardware as possible (dmesg, kernel config, lspci -vvv -xxx
> before susped and if possible PCI configuration dumped from kernel
> after suspend)?
>
> What is the current state of IDE ACPI patches?
> Were the issues raised on linux-ide addressed?
I haven't seen any updates to the drivers/ide/ patch from
Shaohua Li <[email protected]>. I'm beginning to work on
PATA ACPI object support that is similar to the current SATA ACPI
patches -- all for libata. Is this the right or wrong thing
to do?
Thanks,
--
~Randy
On 2/3/06, Randy.Dunlap <[email protected]> wrote:
> On Fri, 3 Feb 2006, Bartlomiej Zolnierkiewicz wrote:
>
> > On 2/3/06, Matthew Garrett <[email protected]> wrote:
> > > Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> > >
> > > > This is untrue as Linux has support for setting IDE controller
> > > > and drives. It was added by Benjamin Herrenschmidt in late
> > > > 2.5.x or early 2.6.x (I don't remember exact kernel version).
> > >
> > > In generic_ide_resume, rqpm.pm_step gets set to
> > > ide_pm_state_start_resume and ide_do_drive_cmd gets called. This ends up
> > > being passed through to start_request. start_request waits for the BSY
> > > bit to go away. On the affected hardware I've seen, this never happens
> > > unless the ACPI calls are made. As far as I can tell, there's nothing in
> > > the current driver code that does anything to make sure that the bus is
> > > in a state to accept commands at this point - the pci drivers don't (for
> > > the most part) seem to have any resume methods. Calling the ACPI _STM
> > > method before attempting to do this magically makes everything work.
> >
> > I don't see anything that prevents addition of ->suspend and ->resume
> > for IDE PCI host drivers (not IDE core issue) if some special sequence
> > is needed.
> >
> > I see that we may be doing PIO/DMA setup too late (IDE core issue)
> > for some controllers.
> >
> > Could you fill a bug at kernel bugzilla with data as much data about
> > affected hardware as possible (dmesg, kernel config, lspci -vvv -xxx
> > before susped and if possible PCI configuration dumped from kernel
> > after suspend)?
> >
> > What is the current state of IDE ACPI patches?
> > Were the issues raised on linux-ide addressed?
>
> I haven't seen any updates to the drivers/ide/ patch from
> Shaohua Li <[email protected]>. I'm beginning to work on
> PATA ACPI object support that is similar to the current SATA ACPI
> patches -- all for libata. Is this the right or wrong thing
> to do?
Working on patches is always right thing to do... 8)
Just one remark: please try to make ACPI part
as libata/SCSI independent as possible.
Thanks,
Bartlomiej
On Fri, 3 Feb 2006, Bartlomiej Zolnierkiewicz wrote:
> On 2/3/06, Randy.Dunlap <[email protected]> wrote:
> > On Fri, 3 Feb 2006, Bartlomiej Zolnierkiewicz wrote:
> >
> > > On 2/3/06, Matthew Garrett <[email protected]> wrote:
> > > > Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> > > >
> > > > > This is untrue as Linux has support for setting IDE controller
> > > > > and drives. It was added by Benjamin Herrenschmidt in late
> > > > > 2.5.x or early 2.6.x (I don't remember exact kernel version).
> > > >
> > > > In generic_ide_resume, rqpm.pm_step gets set to
> > > > ide_pm_state_start_resume and ide_do_drive_cmd gets called. This ends up
> > > > being passed through to start_request. start_request waits for the BSY
> > > > bit to go away. On the affected hardware I've seen, this never happens
> > > > unless the ACPI calls are made. As far as I can tell, there's nothing in
> > > > the current driver code that does anything to make sure that the bus is
> > > > in a state to accept commands at this point - the pci drivers don't (for
> > > > the most part) seem to have any resume methods. Calling the ACPI _STM
> > > > method before attempting to do this magically makes everything work.
> > >
> > > I don't see anything that prevents addition of ->suspend and ->resume
> > > for IDE PCI host drivers (not IDE core issue) if some special sequence
> > > is needed.
> > >
> > > I see that we may be doing PIO/DMA setup too late (IDE core issue)
> > > for some controllers.
> > >
> > > Could you fill a bug at kernel bugzilla with data as much data about
> > > affected hardware as possible (dmesg, kernel config, lspci -vvv -xxx
> > > before susped and if possible PCI configuration dumped from kernel
> > > after suspend)?
> > >
> > > What is the current state of IDE ACPI patches?
> > > Were the issues raised on linux-ide addressed?
> >
> > I haven't seen any updates to the drivers/ide/ patch from
> > Shaohua Li <[email protected]>. I'm beginning to work on
> > PATA ACPI object support that is similar to the current SATA ACPI
> > patches -- all for libata. Is this the right or wrong thing
> > to do?
>
> Working on patches is always right thing to do... 8)
Of course. That wasn't really the question. 8;)
> Just one remark: please try to make ACPI part
> as libata/SCSI independent as possible.
You sort of replied obliquely to my "all for libata" comment.
These patches are all libata-specific.
At least they are SCSI-independent. :)
--
~Randy
On Friday 03 February 2006 15:29, Olivier Galibert wrote:
> On Fri, Feb 03, 2006 at 11:41:29AM +0100, Pavel Machek wrote:
> > > I don't even want to think about the interactions
> > > between freezing the userspace memory pages and running some processes
> > > which may malloc/mmap at the same time.
> >
> > There are none. userspace helper is mlocked, and rest of userspace is
> > stopped.
>
> Unless the userspace code is as tight as mission-critical RT code, I
> don't see how that can work reliably.
I use it on a daily basis. It works.
> Some problems I see:
>
> - What happens if the helper faults in new pages, changes its brk or
> mmaps things? Can we actually swap at that point?
Yes.
> mlocking takes care of the fault in, not of the rest.
>
> - What happens if the helper reads files? Where will the pages with
> the file data be put? Are we saving the dcache in the image, and if
> yes which state of the dcache?
The suspending helper should not use mounted filesystems after it
calls the atomic snapshot ioctl(). The resuming helper should be run from
an initrd and all filesystems should be unmounted at that time (of course
it should not attempt to mount them).
Please read the Documentation/power/userland-swsusp.txt file in the latest -mm
and you'll get an idea of how it works.
> - What happens if the helper writes files? What state are we saving,
> before starting the helper or after?
After.
> Will the fs be in a coherent state after resume?
Yes, it will, as long as the helpers follow some strict rules (above).
> - What about IPC? What if for instance the helper tries to contact
> HAL to get some system information?
That doesn't matter.
> And if you decide on rules on what the userspace can and can't do, how
> do you plan to enforce them? We have filesystems on the line there,
> you don't want them destroyed at resume because the latest version of
> kdome-resume-progress-bar thought it was cool to generate an picture
> of the desktop at suspend time to show at resume.
>
> The idea of trying to save a state that can be modified dynamically
> while you're saving in unpredictable ways makes me very, very afraid.
> At least when you're in the kernel you can have complete control over
> the machine when needed.
Not necessarily. For example, if you suspend the box and then start it with
a wrong kernel that is unable to read the image, it will mount the file
systems and you loose the saved state.
Greetings,
Rafael
On Fri, Feb 03, 2006 at 06:24:44PM +0100, Rafael J. Wysocki wrote:
> I use it on a daily basis. It works.
The plural of anecdote is not data. Nobody except Pavel and you ever
wrote code to work in the userland part of your suspend. But the aim
is to have GUI-type code written by other people running between the
snapshotting and the system shutdown, right? Code that is pretty much
by definition just plain untrustable in the first place.
The interactions with a frozen, direct-rendering X are going to be
quite amusing too. You'll have to be very careful to switch VTs to a
suspend-aware framebuffer before snapshotting. That could help
reducing your video-card related problems though.
> The suspending helper should not use mounted filesystems after it
> calls the atomic snapshot ioctl().
You can s/mounted// on that. It's pretty much impossible to unmount
filesystems on a running system, it's always kept busy by something.
Especially system filesystems.
> The resuming helper should be run from
> an initrd and all filesystems should be unmounted at that time (of course
> it should not attempt to mount them).
Mandatory initrd? How nice...
> > Will the fs be in a coherent state after resume?
>
> Yes, it will, as long as the helpers follow some strict rules (above).
That's exactly what I'm terribly afraid of. You have no way to
enforce them, so they won't be respected. And filesystems will die
randomly and unpredictably.
> > The idea of trying to save a state that can be modified dynamically
> > while you're saving in unpredictable ways makes me very, very afraid.
> > At least when you're in the kernel you can have complete control over
> > the machine when needed.
>
> Not necessarily. For example, if you suspend the box and then start it with
> a wrong kernel that is unable to read the image, it will mount the file
> systems and you loose the saved state.
You can always limit the damage by syncing the disks before
snapshotting. This way you'll only lose the running processes if you
don't actually resume. While having the in-memory cache of the state
of the filesystem being different of the real on-disk state eats
filesystems for breakfast. The output of fsck is not pretty.
BTDTGTTS.
OG.
On 2/3/06, Randy.Dunlap <[email protected]> wrote:
> On Fri, 3 Feb 2006, Bartlomiej Zolnierkiewicz wrote:
>
> > On 2/3/06, Randy.Dunlap <[email protected]> wrote:
> > > On Fri, 3 Feb 2006, Bartlomiej Zolnierkiewicz wrote:
> > >
> > > > On 2/3/06, Matthew Garrett <[email protected]> wrote:
> > > > > Bartlomiej Zolnierkiewicz <[email protected]> wrote:
> > > > >
> > > > > > This is untrue as Linux has support for setting IDE controller
> > > > > > and drives. It was added by Benjamin Herrenschmidt in late
> > > > > > 2.5.x or early 2.6.x (I don't remember exact kernel version).
> > > > >
> > > > > In generic_ide_resume, rqpm.pm_step gets set to
> > > > > ide_pm_state_start_resume and ide_do_drive_cmd gets called. This ends up
> > > > > being passed through to start_request. start_request waits for the BSY
> > > > > bit to go away. On the affected hardware I've seen, this never happens
> > > > > unless the ACPI calls are made. As far as I can tell, there's nothing in
> > > > > the current driver code that does anything to make sure that the bus is
> > > > > in a state to accept commands at this point - the pci drivers don't (for
> > > > > the most part) seem to have any resume methods. Calling the ACPI _STM
> > > > > method before attempting to do this magically makes everything work.
> > > >
> > > > I don't see anything that prevents addition of ->suspend and ->resume
> > > > for IDE PCI host drivers (not IDE core issue) if some special sequence
> > > > is needed.
> > > >
> > > > I see that we may be doing PIO/DMA setup too late (IDE core issue)
> > > > for some controllers.
> > > >
> > > > Could you fill a bug at kernel bugzilla with data as much data about
> > > > affected hardware as possible (dmesg, kernel config, lspci -vvv -xxx
> > > > before susped and if possible PCI configuration dumped from kernel
> > > > after suspend)?
> > > >
> > > > What is the current state of IDE ACPI patches?
> > > > Were the issues raised on linux-ide addressed?
> > >
> > > I haven't seen any updates to the drivers/ide/ patch from
> > > Shaohua Li <[email protected]>. I'm beginning to work on
> > > PATA ACPI object support that is similar to the current SATA ACPI
> > > patches -- all for libata. Is this the right or wrong thing
> > > to do?
> >
> > Working on patches is always right thing to do... 8)
>
> Of course. That wasn't really the question. 8;)
>
> > Just one remark: please try to make ACPI part
> > as libata/SCSI independent as possible.
>
> You sort of replied obliquely to my "all for libata" comment.
> These patches are all libata-specific.
Yes, developing for libata-only should be much easier to do.
We can backport it to IDE if/when needed later.
Just a reminder so nobody gets a wrong idea:
the above is in perfect harmony with my opinion wrt libata
PATA support - IDE driver should evolve and be merged
with libata (evolutionary vs revolutionary).
> At least they are SCSI-independent. :)
Well at least not directly. :)
Bartlomiej
On Friday 03 February 2006 19:30, Olivier Galibert wrote:
> On Fri, Feb 03, 2006 at 06:24:44PM +0100, Rafael J. Wysocki wrote:
> > I use it on a daily basis. It works.
>
> The plural of anecdote is not data. Nobody except Pavel and you ever
> wrote code to work in the userland part of your suspend. But the aim
> is to have GUI-type code written by other people running between the
> snapshotting and the system shutdown, right? Code that is pretty much
> by definition just plain untrustable in the first place.
By the same token any code that's run as/by root is untrastable and it can
destroy the system just as well.
> The interactions with a frozen, direct-rendering X are going to be
> quite amusing too. You'll have to be very careful to switch VTs to a
> suspend-aware framebuffer before snapshotting. That could help
> reducing your video-card related problems though.
Yes. We are switching to a VT before snapshotting the system.
> > The suspending helper should not use mounted filesystems after it
> > calls the atomic snapshot ioctl().
>
> You can s/mounted// on that. It's pretty much impossible to unmount
> filesystems on a running system, it's always kept busy by something.
> Especially system filesystems.
I mean it shouldn't read files from such filesystems or write to them. They
are mounted all the time and should not be unmounted, of course.
> > The resuming helper should be run from
> > an initrd and all filesystems should be unmounted at that time (of course
> > it should not attempt to mount them).
>
> Mandatory initrd? How nice...
Why? It's quite easy to set up and virtually all distributions use it anyway.
> > > Will the fs be in a coherent state after resume?
> >
> > Yes, it will, as long as the helpers follow some strict rules (above).
>
> That's exactly what I'm terribly afraid of. You have no way to
> enforce them, so they won't be respected. And filesystems will die
> randomly and unpredictably.
Yes, this may happen if the userland helpers are buggy, but again any
root-equivalent process that is buggy can do the damage just as well.
Your point seem to be "we should implement this in the kernel to protect
the users from irresponsible authors of userland applications
and distributors". I just don't agree with that. [Going along this line of
reasoning we should implement fsck in the kernel too. ;-)]
> > > The idea of trying to save a state that can be modified dynamically
> > > while you're saving in unpredictable ways makes me very, very afraid.
> > > At least when you're in the kernel you can have complete control over
> > > the machine when needed.
> >
> > Not necessarily. For example, if you suspend the box and then start it with
> > a wrong kernel that is unable to read the image, it will mount the file
> > systems and you loose the saved state.
>
> You can always limit the damage by syncing the disks before
> snapshotting.
Yes, we are doing that already and we are working on improving it further
(just now :-)).
Still, if you don't like the idea of userland-based suspend, we are not going
to remove the kernel-based suspend, AFAICT.
Greetings,
Rafael
Hi.
On Friday 03 February 2006 18:57, Rafael J. Wysocki wrote:
> Hi,
>
> On Friday 03 February 2006 01:20, Nigel Cunningham wrote:
> > On Friday 03 February 2006 08:10, Rafael J. Wysocki wrote:
> > > I was referring to the (not so far) future situation when we have
> > > compression in the userland suspend/resume utilities. The times of
> > > writing/reading the image will be similar to yours and IMHO it's
> > > usually possible to free 1/2 of RAM in a box with 512+ MB of RAM at a
> > > little cost as far as the responsiveness after resume is concerned.
> > > Thus on machines with 512+ MB of RAM
> > > both solutions will give similar results performance-wise, but the
> > > userland-driven suspend gives you much more flexibility wrt what you
> > > can do with the image (eg. you can even send it over the network if
> > > need be).
> > >
> > > On machines with less RAM suspend2 will probably be better
> > > preformance-wise, and that may be more important than the flexibility.
> >
> > Ok. So I bit the bullet and downloaded -mm4 to take a look at this
> > interface you're making, and I have a few questions:
> >
> > - It seems to be hardwired to use swap, but you talk about writing to a
> > network image above. In Suspend2, I just bmap whatever the storage is,
> > and then submit bios to read and write the data. Is anything like that
> > possible with this interface? (Could it be extended if not?)
>
> The swap partition was easy. :-) However, there is the bmap() call that
> userspace processes can use, so it seems to be possible. [BTW, the network
> is easy too, because it desn't require us to tamper with disks while
> suspended.]
Yes. I already did suspend to network last March, but haven't spent more time
on it since - it wasn't working perfectly, but it was working using a
modified userspace nbd client.
> > - Is there any way you could support doing a full image of memory with
> > this approach?
>
> I'm not sure, but I think that's possible. For now I don't see major
> obstacles, but honestly I'll have to read your code (and understand it)
> to answer this question responsibly.
Ditto in reverse. I have to admit I'm still struggling to see what the
advantage to userspace is. At the moment, it seems to me like nothing more
than an extra layer of complexity and new possibilities for failure. Maybe my
attitude will change when I look at it more.
> > Would you take patches?
>
> Well, the code in question is already in the kernel (in -mm, but this
> doesn't matter here) and I'm not the maintainer of it, so I can't answer
> this question directly. However, if you asked me whether I would _support_
> any patches, I would say I had never opposed or supported a patch whithout
> trying to understand it.
>
> When I think I understand the patch, I try to value it, and I have two
> rules here:
> 1) The released code should always be functional. [So I never submit
> untested patches without saying explicitly that they are untested and if I
> replace some code A with alternative code B, I do my best to ensure it
> won't break any existing setups.]
> 2) The software with this patch applied must be such that I would like to
> run it on my computer. [If I wouldn't, there's no chance I'll support it.]
No problems there. I only reboot when forced to, and suspend to disk by
default (or to put it another way, I eat my own dog food).
> > - Does the data have to be transferred to userspace? Security and
> > efficiency wise, it would seem to make a lot more sense just to be
> > telling the kernel where to write things and let it do bio calls like I'm
> > doing at the moment.
>
> First, there's a difference between efficiency and performance.
>
> For example, the kernel already contains the code for writing data to the
> disk or partition you are using for suspend. By using bio directly to
> write to it you're duplicating the functionality of that code which is
> _inefficient_, although this need not be related to performance. Worse
> yet, if some optimizations go to this code, you won't have them unless you
> notice and implement them once again.
>
> Similar observation applies to enryption and compression: There are
> libraries for encryption and compression that contain lots of different
> algorithms, so why should we try to duplicate that code? It is more
> efficient to _use_ it, which can be done easily in the user space.
That's why I want to use the existing bio calls and crypto api support. I
don't use the swap read/write routines because... well I've forgotten the
reason 3 years later. Let me take a guess though - using swap routines might
corrupt LRU? One thing I do know is that the filewriter and swapwriter use
the same code to do the writing. I'd be more accurate in calling them
swap/file allocators now, as they really only calculate where to store the
image (and associated functions).
> This may hurt performance a bit, but usually not so far that anyone will
> notice. [Actually on my box the suspending and resuming userland
> utilities I use for testing perform the I/O-related operations _faster_
> than the built-in swsusp code, although they seemingly do the same
> things.]
Strange.
> Second, as far as the security is concerned, the only problem I see is that
> a malicious attacker may be able to read unencrypted suspend image from the
> system or submit his own specially crafted image which would require
> root-equivalent access anyway. However to prevent this you can set
> whatever paranoid permissions you desire on /dev/snapshot and implement
> your suspending utility as a daemon running in a privileged security ring
> (the resume is run from and initrd anyway).
True, and an unencrypted image on disk is as vulnerable as any other data on
disk anyway.
> The biggest advantage of the userland-based approach I see is that there
> may be _many_ implementations of the suspending and resuming tools
> and they will not conflict. For example, if Distributor X needs an exotic
> feature Y wrt suspend (various vendor-specific eye-candies come to mind or
> transferring the image over a network), he can implement it in his userland
> tools without modifying the kernel. Similarly, if Vendor V wants to use
> paranoid encryption algorithm Z to encrypt the image, she can do that
> _herself_ in the user space.
True, but can you really imagine people doing that? The one instance I can
think of was the donation of LZF support to Suspend2 a couple of years back.
> We only need to provide reference tools and we won't be asked to implement
> every feature that people may want in the kernel.
I don't want it to be true, but I think you're being naive in saying that :)
We'll see, won't we?
> > - In your Documentation file, you say say opening /dev/snapshot for
> > reading is done when suspending. Shouldn't that be open read for resume
> > and write for suspend?
>
> No. During suspend the image is read from the kernel and saved by a
> userland tool and analogously during resume.
Oh ok.
> > I'm not saying I'm going to get carried away trying to port Suspend2 to
> > userspace. Just tentatively exploring. But if I did decide to port it, my
> > default position would be to seek not to drop a single feature. I hope
> > that's not too unreasonable!
>
> That's fine. I think we have the same goal which is a reasonable set of
> features available to the users.
>
> [Heh, that looks like a good starter for the userland suspend FAQ. Perhaps
> I should save this message. ;-)]
Thanks.
Nigel
> Greetings,
> Rafael
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Friday 03 February 2006 23:16, Pavel Machek wrote:
> On P? 03-02-06 10:20:42, Nigel Cunningham wrote:
> > Hi.
> >
> > On Friday 03 February 2006 08:10, Rafael J. Wysocki wrote:
> > > On machines with less RAM suspend2 will probably be better
> > > preformance-wise, and that may be more important than the flexibility.
> >
> > Ok. So I bit the bullet and downloaded -mm4 to take a look at this
> > interface you're making, and I have a few questions:
>
> Great, thanks.
>
> > - It seems to be hardwired to use swap, but you talk about writing to a
> > network image above. In Suspend2, I just bmap whatever the storage is,
> > and then submit bios to read and write the data. Is anything like that
> > possible with this interface? (Could it be extended if not?)
>
> No, it is not hardwired. There's special swap support, but you do not
> need to use it.
>
> > - Is there any way you could support doing a full image of memory with
> > this approach? Would you take patches?
>
> Doing full image is certainly possible; it is not important if kernel
> does the writing or userspace does it. Taking patches definitely
> depends how they'd look like...
Would you actually do some work on generating them? I'm concerned that I'm
going to end up putting more work into making patches, only to have you nack
them for (what seem to me like) arbitrary reasons. I feel like all you're
doing at the moment is pouring cold water on my work. Seeing you put some
work into making mileage from the work I've put into Suspend2 would encourage
me a lot. Forgive me if I sound pretty negative - between a couple of months
of humid weather, lack of sleep and the event of the last few weeks, I'm not
in the best frame of mind at the moment. Perhaps it would be better for me
just to say "I give full permission for you and Rafael to rip out of Suspend2
anything you find useful.", leave it at that and go find another hobby for a
while.
Regards,
Nigel
> > - Does the data have to be transferred to userspace? Security and
> > efficiency wise, it would seem to make a lot more sense just to be
> > telling the kernel where to write things and let it do bio calls like I'm
> > doing at the moment.
>
> As far as I can see, transfering data to userspace and back does not
> really cost much:
>
> pavel@amd:~$ time head -c $[1024*1024*1024] < /dev/zero > /dev/null
> 0.16user 0.27system 0.43 (0m0.439s) elapsed 100.00%CPU
>
> ...2000MB/sec is the limit (thinkpad x32).
> Pavel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On P? 03-02-06 15:29:15, Olivier Galibert wrote:
> On Fri, Feb 03, 2006 at 11:41:29AM +0100, Pavel Machek wrote:
> > > I don't even want to think about the interactions
> > > between freezing the userspace memory pages and running some processes
> > > which may malloc/mmap at the same time.
> >
> > There are none. userspace helper is mlocked, and rest of userspace is
> > stopped.
>
> Unless the userspace code is as tight as mission-critical RT code, I
> don't see how that can work reliably. Some problems I see:
It needs to be tight. Helper may not do anything below after it frozen
rest of userland.
> - What happens if the helper faults in new pages, changes its brk or
> mmaps things? Can we actually swap at that point? mlocking takes
> care of the fault in, not of the rest.
>
> - What happens if the helper reads files? Where will the pages with
> the file data be put? Are we saving the dcache in the image, and if
> yes which state of the dcache?
>
> - What happens if the helper writes files? What state are we saving,
> before starting the helper or after? Will the fs be in a coherent
> state after resume?
>
> - What about IPC? What if for instance the helper tries to contact
> HAL to get some system information?
>
> And if you decide on rules on what the userspace can and can't do, how
> do you plan to enforce them? We have filesystems on the line there,
We don't "enforce" rules in kernel, too, still it seems to
work. Helper needs similar level of auditing to kernel code. It is not
your average GUI application.
> The idea of trying to save a state that can be modified dynamically
> while you're saving in unpredictable ways makes me very, very afraid.
> At least when you're in the kernel you can have complete control over
> the machine when needed.
Take a look at code. State is still atomically snapshoted with
interrupts disabled, in kernel.
Pavel
--
Thanks, Sharp!
Hi!
On P? 03-02-06 21:47:18, Nigel Cunningham wrote:
> On Friday 03 February 2006 18:57, Rafael J. Wysocki wrote:
> > On Friday 03 February 2006 01:20, Nigel Cunningham wrote:
> > > On Friday 03 February 2006 08:10, Rafael J. Wysocki wrote:
> > The biggest advantage of the userland-based approach I see is that there
> > may be _many_ implementations of the suspending and resuming tools
> > and they will not conflict. For example, if Distributor X needs an exotic
> > feature Y wrt suspend (various vendor-specific eye-candies come to mind or
> > transferring the image over a network), he can implement it in his userland
> > tools without modifying the kernel. Similarly, if Vendor V wants to use
> > paranoid encryption algorithm Z to encrypt the image, she can do that
> > _herself_ in the user space.
>
> True, but can you really imagine people doing that? The one instance I can
> think of was the donation of LZF support to Suspend2 a couple of
> years back.
Yes, I expect them to do so. Desktop distros have different needs than
for example embedded vendors, wanting to use swsusp for fast boot.
> > We only need to provide reference tools and we won't be asked to implement
> > every feature that people may want in the kernel.
>
> I don't want it to be true, but I think you're being naive in saying that :)
> We'll see, won't we?
I think I have a volunteer inside suse doing at least some of userland
swsusp work.
Pavel
--
Thanks, Sharp!
On Fri, 2006-02-03 at 12:44 +0100, Pavel Machek wrote:
> [Pavel is willing to take patches, as his cooperation with Rafael
> shows, but is scared by both big patches and series of 10 small
> patches he does not understand. He likes patches removing code.]
Yeah, new features are going to happen by removing code. And I don't get
this "scared of patches I don't understand" thing. Every time I asked
Nigel a question, he replied and it wasn't rubbish.
--
Bojan
On Fri, 2006-02-03 at 12:49 +0100, Pavel Machek wrote:
> > - it is reliable (e.g. I have suspended/resumed mid kernel compile -
> > actually, kernel RPM build, which included compile - many times,
> > without any ill effect)
>
> Rafael has test patch for this one.
Great. It's been like this for *months* with suspend2.
> > - it is fast (i.e. even on my crappy old HP ZE4201
> > [http://www.rexursive.com/articles/linuxonhpze4201.html], it writes all
> > of 700+ MB of RAM to disk just as fast or faster than swsusp).
>
> Help us with userland parts of uswsusp, pretty please?
Sure, if I find time I will.
> > - it looks nice (both text and GUI interface supported)
>
> Planned for userland parts.
As I said before - it's going to be years. Never mind that all this
stuff exists in suspend2 now.
> > - it leaves the system responsive on resume (kinda nice to come back to
> > X and "Just Use it")
>
> Merged in latest mainline.
Great.
> > - it suspends to both swap and file (I personally use swap, but many
> > people on the list use file)
>
> Doable in userland parts; not sure with someone plans it.
Again - stuff is there, but for some weird reason it's not good enough.
Instead of using what's there and works reliably while developing the
next big thing, we'll be back where we were - no decent suspend/resume
support for a while. Excellent.
Whatever happened to release early, release often?
> Can you do usual "try again with minimum drivers" debugging?
Here is the thing - I don't have to do this with suspend2. Why is it
that suspend2 code overcomes the obstacles that swsusp can't? This is
rhetorical, of course.
Anyhow, if I find time, I will.
--
Bojan
Hi!
> > > - Is there any way you could support doing a full image of memory with
> > > this approach? Would you take patches?
> >
> > Doing full image is certainly possible; it is not important if kernel
> > does the writing or userspace does it. Taking patches definitely
> > depends how they'd look like...
>
> Would you actually do some work on generating them?
Well, I'm afraid that full image of memory is not that high on
priority list. Rafael's solution seems to work pretty much okay.
> I'm concerned that I'm
> going to end up putting more work into making patches, only to have you nack
> them for (what seem to me like) arbitrary reasons. I feel like all you're
> doing at the moment is pouring cold water on my work. Seeing you put
> some
Well, sorry about that. I thought I gave you fair warning at the end
of last year, when I posted uswsusp patches to the lists...
> work into making mileage from the work I've put into Suspend2 would encourage
> me a lot. Forgive me if I sound pretty negative - between a couple of months
> of humid weather, lack of sleep and the event of the last few weeks, I'm not
> in the best frame of mind at the moment. Perhaps it would be better
> for me
Well, you did some pretty amazing work with suspend2.net community...
> just to say "I give full permission for you and Rafael to rip out of Suspend2
> anything you find useful.", leave it at that and go find another hobby for a
> while.
We could use some help with userland tools. Helping with userland
parts is probably the fastest way to get usable/nice/fast suspend to
the users.
If you think suspend2 can be easily ported to userspace... yes, that
would be useful/welcome.
Pavel
--
Thanks, Sharp!
On So 04-02-06 10:43:24, Bojan Smojver wrote:
> On Fri, 2006-02-03 at 12:49 +0100, Pavel Machek wrote:
> > > - it looks nice (both text and GUI interface supported)
> >
> > Planned for userland parts.
>
> As I said before - it's going to be years. Never mind that all this
> stuff exists in suspend2 now.
I hope it will be a *year*. If we get more users helping, it will be
sooner.
> > > - it suspends to both swap and file (I personally use swap, but many
> > > people on the list use file)
> >
> > Doable in userland parts; not sure with someone plans it.
>
> Again - stuff is there, but for some weird reason it's not good
> enough.
The weird reasons were stated few times already. My favourite weird
reason is "can be done in userspace" these days.
Pavel
--
Thanks, Sharp!
On Sat, 2006-02-04 at 00:55 +0100, Pavel Machek wrote:
> The weird reasons were stated few times already. My favourite weird
> reason is "can be done in userspace" these days.
OK, let me give you the user perspective again:
- can I use vanilla kernel suspend support now: NO
- can I use suspend2 suspend support now: YES
- would I like things to improve even more: YES
I don't know why we have to wait a year to have decent suspend support.
By developing uswsusp, you are pretty much agreeing with me - current
kernel stuff isn't working to your (or mine) satisfaction. Now, I know
uswsusp is going to be better than sliced bread, but wouldn't it be nice
if more people could actually use their notebooks properly in the
meantime?
--
Bojan
On Fri, Feb 03, 2006 at 10:08:57PM +0100, Rafael J. Wysocki wrote:
> By the same token any code that's run as/by root is untrastable and it can
> destroy the system just as well.
Yes, and that's why old timers essentially never run GUI code as root.
The quality of that code tends to be... sloppy compared to the
standards of setuid code or kernel code.
> > That's exactly what I'm terribly afraid of. You have no way to
> > enforce them, so they won't be respected. And filesystems will die
> > randomly and unpredictably.
>
> Yes, this may happen if the userland helpers are buggy, but again any
> root-equivalent process that is buggy can do the damage just as well.
>
> Your point seem to be "we should implement this in the kernel to protect
> the users from irresponsible authors of userland applications
> and distributors". I just don't agree with that. [Going along this line of
> reasoning we should implement fsck in the kernel too. ;-)]
fsck isn't sexy and is implemented by the authors of the filesystems
or in close collaboration with them. Even there, there is a lot of
talk about fscking live systems but nobody has dared it yet. That has
some similarities with your situation.
There are two parts in your suspend userland helper. The
functionality code, which you, and Pavel, and other highly competent
people will write. I have no qualms with that one. And then there is
the chrome code, the sexy code, that everybody and his dog is going to
want to muck with because that's where the looks are. I'll give it 6
months at best from when you have a working system before you get a
submission for some themed, 3d-accelerated buzzword-compliant
nightmare of a progress bar. With demented pressure to have it in the
official distribution because it looks like Babylon 5 on steroids.
Especially if you have a plugin structure, which otherwise makes a lot
of sense technically. Will you be able to trust this code to do no
disk access and no other state changes that could be problematic (like
changing vt back to X)?
In other words, opening a window between the snapshot and the shutdown
for look-oriented code you won't control may not be a can of worms you
really want to have to handle.
While from the kernel side you can close the access to what you do not
want disturbed.
OG.
On Sat, Feb 04, 2006 at 12:55:47AM +0100, Pavel Machek wrote:
> The weird reasons were stated few times already. My favourite weird
> reason is "can be done in userspace" these days.
Oh please, stop that. Network can be done in userspace. NFS can be
done in userspace. Filesystems can be done in userspace. You need a
better reason than that.
Now the pressure to add progress bar and other chrome, I can
understand. Not wanting the chrome in the kernel, I understand even
more. Deciding the solution for that is to more everything in
userspace and end up with the quality and stability of the suspend
fonctionality hostage to the quality of chrome code, I don't
understand that one. Have you seen the state of multimedia playing
applications lately, where chrome won over functionality? It's
dreadful, even if flashy.
Why don't you try to design the system so that the progress bar can't
fuck up the suspend unless they really, really want to? Instead of
one where a forgotten open(O_CREAT) in a corner of graphics code can
randomly trash the filesystem through metadata corruption?
OG.
Hi!
> > > That's exactly what I'm terribly afraid of. You have no way to
> > > enforce them, so they won't be respected. And filesystems will die
> > > randomly and unpredictably.
> >
> > Yes, this may happen if the userland helpers are buggy, but again any
> > root-equivalent process that is buggy can do the damage just as well.
> >
> > Your point seem to be "we should implement this in the kernel to protect
> > the users from irresponsible authors of userland applications
> > and distributors". I just don't agree with that. [Going along this line of
> > reasoning we should implement fsck in the kernel too. ;-)]
>
> fsck isn't sexy and is implemented by the authors of the filesystems
> or in close collaboration with them. Even there, there is a lot of
> talk about fscking live systems but nobody has dared it yet. That has
> some similarities with your situation.
>
> There are two parts in your suspend userland helper. The
> functionality code, which you, and Pavel, and other highly competent
> people will write. I have no qualms with that one. And then there
> is
Thanks :-).
> the chrome code, the sexy code, that everybody and his dog is going to
> want to muck with because that's where the looks are. I'll give it 6
> months at best from when you have a working system before you get a
> submission for some themed, 3d-accelerated buzzword-compliant
> nightmare of a progress bar. With demented pressure to have it in
> the
Well, this should be more like bootsplash support; simple, preload
bitmaps before you start suspend sequence, no 3d-accelerated
hell. I'll actually make sure I have reasonably-looking progress bar
ready, so people don't have reason to invent some nightmare.
> official distribution because it looks like Babylon 5 on steroids.
> Especially if you have a plugin structure, which otherwise makes a lot
> of sense technically. Will you be able to trust this code to do no
> disk access and no other state changes that could be problematic (like
> changing vt back to X)?
If they try to switch back to X, it will just deadlock on them. If
they try to communicate using IPC, boom, deadlock. They still may do
something stupid; I'll do my best to educate them not to do
that. Writing to filesystem would be especially bad, for example. But
that should be reasonably easy to understand...
Pavel
--
Thanks, Sharp!
On 2/2/06, Andrew Morton <[email protected]> wrote:
> Random thoughts:
>
> - swsusp has been a multi-year ongoing source of churn and bug reports.
> It hasn't been a big success and we have a way to go yet.
swsusp may be an ongoing source of churn and bug reports, but it's
also been more reliable for me (on multiple types of hardware) than
Windows XP hibernate. In fact, at this point I'm perfectly satisfied
with its reliability (i.e. I haven't had any problems lately).
(I just figure that I need to speak up, as a highly satisfied swsusp user.)
--
-Barry K. Nathan <[email protected]>
On So 04-02-06 01:36:59, Olivier Galibert wrote:
> On Sat, Feb 04, 2006 at 12:55:47AM +0100, Pavel Machek wrote:
> > The weird reasons were stated few times already. My favourite weird
> > reason is "can be done in userspace" these days.
>
> Oh please, stop that. Network can be done in userspace. NFS can be
> done in userspace. Filesystems can be done in userspace. You need a
> better reason than that.
I have few more. That was my favourite :-).
> Now the pressure to add progress bar and other chrome, I can
> understand. Not wanting the chrome in the kernel, I understand even
> more. Deciding the solution for that is to more everything in
Good.
> Why don't you try to design the system so that the progress bar can't
> fuck up the suspend unless they really, really want to? Instead of
> one where a forgotten open(O_CREAT) in a corner of graphics code can
> randomly trash the filesystem through metadata corruption?
Even if I only put chrome code to userspace, open() would still be
deadly. I could do something fancy with disallowing syscalls, but it
is probably easier to just read the chrome code to be used... It
should be as simple as memcpy(framebuffer, prepared image).
Pavel
--
Thanks, Sharp!
On Sat, Feb 04, 2006 at 01:49:44AM +0100, Pavel Machek wrote:
> > Why don't you try to design the system so that the progress bar can't
> > fuck up the suspend unless they really, really want to? Instead of
> > one where a forgotten open(O_CREAT) in a corner of graphics code can
> > randomly trash the filesystem through metadata corruption?
>
> Even if I only put chrome code to userspace, open() would still be
> deadly. I could do something fancy with disallowing syscalls,
Nah, simply chroot to an empty virtual filesystem (a tmpfs with max
size=0 will do) and they can't do any fs-related fuckup anymore. Just
give them a fd through which request some specific resources
(framebuffer mmap essentially I would say) and exchange messages with
the suspend system (status, cancel, etc) and maybe log stderr for
debugging purposes and that's it. They can't do damage by mistake
anymore. They can always send signals to random pids, but that's not
called a mistake at that point.
Even better, you can run _multiple_ processes that way, some for
compression/encryption, some for chrome, etc.
> but it
> is probably easier to just read the chrome code to be used... It
> should be as simple as memcpy(framebuffer, prepared image).
I guess I just can't trust chrome code. I've have seen too much of it
to be able to. Especially since once you open the gates a simple
animated-gif equivalent won't be considered enough, and userland code
does not go through the same kind of filters kernel code does.
Anybody and his dog will be able to take your userland suspend code,
add their neogeo emulator to play while it's suspending, and then
point at you when their fs got eaten after the tenth reboot. And
distribs will pick it up because it's cool.
OG.
Hi Pavel.
On Friday 03 February 2006 21:44, Pavel Machek wrote:
> [Pavel is willing to take patches, as his cooperation with Rafael
> shows, but is scared by both big patches and series of 10 small
> patches he does not understand. He likes patches removing code.]
Assuming you're refering to the patches that started this thread, what don't
you understand? I'm more than happy to explain.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On So 04-02-06 02:08:33, Olivier Galibert wrote:
> On Sat, Feb 04, 2006 at 01:49:44AM +0100, Pavel Machek wrote:
> > > Why don't you try to design the system so that the progress bar can't
> > > fuck up the suspend unless they really, really want to? Instead of
> > > one where a forgotten open(O_CREAT) in a corner of graphics code can
> > > randomly trash the filesystem through metadata corruption?
> >
> > Even if I only put chrome code to userspace, open() would still be
> > deadly. I could do something fancy with disallowing syscalls,
>
> Nah, simply chroot to an empty virtual filesystem (a tmpfs with max
> size=0 will do) and they can't do any fs-related fuckup anymore. Just
> give them a fd through which request some specific resources
> (framebuffer mmap essentially I would say) and exchange messages with
> the suspend system (status, cancel, etc) and maybe log stderr for
> debugging purposes and that's it. They can't do damage by mistake
> anymore. They can always send signals to random pids, but that's not
> called a mistake at that point.
>
> Even better, you can run _multiple_ processes that way, some for
> compression/encryption, some for chrome, etc.
No, I do not want to deal with multiple processes. Chrome code is not
*as* evil as you paint it... But yes, chroot is a nice idea. Doing
chroot into nowhere after freezing system will prevent most stupid
mistakes. Rest of userland is frozen, so it can not do anything really
wrong (at most you deadlock), if you kill someone -- well, that's only
as dangerous as any other code running as root.
> > but it
> > is probably easier to just read the chrome code to be used... It
> > should be as simple as memcpy(framebuffer, prepared image).
>
> I guess I just can't trust chrome code. I've have seen too much of it
> to be able to. Especially since once you open the gates a simple
> animated-gif equivalent won't be considered enough, and userland code
> does not go through the same kind of filters kernel code does.
>
> Anybody and his dog will be able to take your userland suspend code,
> add their neogeo emulator to play while it's suspending, and then
> point at you when their fs got eaten after the tenth reboot.
I'm going to solve that one with big warning, at the begining of
suspend program. If someone can't read, I'll laugh at them. How was
your acronym -- BTDTSHTFTS?
[There's similary dangerous code in /sys/power/resume, today. Distros
actually use it. It only costed one filesystem... I killed 3
filesystems myself, and one underlated with memcpy<->strcpy
bug. So... it is not really that dangerous.]
> distribs will pick it up because it's cool.
...don't worry about distros, they are not _that_ stupid, and they are
already doing eye candy at weird places today (grub, kernel).
Pavel
--
Thanks, Sharp!
On Sat, 2006-02-04 at 02:23 +0100, Pavel Machek wrote:
> ...don't worry about distros, they are not _that_ stupid, and they are
> already doing eye candy at weird places today (grub, kernel).
Absolutely. Keep Linux distros ugly at all costs. NOT!
Reality check: People prefer *nice* things that work to things that just
work.
--
Bojan
On So 04-02-06 11:20:54, Nigel Cunningham wrote:
> Hi Pavel.
>
> On Friday 03 February 2006 21:44, Pavel Machek wrote:
> > [Pavel is willing to take patches, as his cooperation with Rafael
> > shows, but is scared by both big patches and series of 10 small
> > patches he does not understand. He likes patches removing code.]
>
> Assuming you're refering to the patches that started this thread, what don't
> you understand? I'm more than happy to explain.
For "suspend2: modules support", it is pretty clear that I do not need
or want that complexity. But for "refrigerator improvements", I did
not understand which parts are neccessary because of suspend2
vs. swsusp differences, and if there is simpler way towards the same
goal. (And thanks for a stress hint...)
Pavel
--
Thanks, Sharp!
Hi.
On Saturday 04 February 2006 19:01, Pavel Machek wrote:
> On So 04-02-06 11:20:54, Nigel Cunningham wrote:
> > Hi Pavel.
> >
> > On Friday 03 February 2006 21:44, Pavel Machek wrote:
> > > [Pavel is willing to take patches, as his cooperation with Rafael
> > > shows, but is scared by both big patches and series of 10 small
> > > patches he does not understand. He likes patches removing code.]
> >
> > Assuming you're refering to the patches that started this thread, what
> > don't you understand? I'm more than happy to explain.
>
> For "suspend2: modules support", it is pretty clear that I do not need
> or want that complexity. But for "refrigerator improvements", I did
... and yet you're perfectly happy to add the complexity of sticking half
the code in userspace. I don't think I'll ever dare to try to understand
you, Pavel :)
> not understand which parts are neccessary because of suspend2
> vs. swsusp differences, and if there is simpler way towards the same
> goal. (And thanks for a stress hint...)
I think virtually everything is relevant to you. A couple of possible
exceptions might be (1) freezing bdevs, because you don't care so much
about making xfs really sync and really stop it's activity and (2) the
ability to thaw kernel space without thawing userspace. I want this for
eating memory, to avoid deadlocking against kjournald etc. I haven't
checked carefully as to why you don't need it in vanilla.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On Saturday 04 February 2006 01:46, Barry K. Nathan wrote:
> On 2/2/06, Andrew Morton <[email protected]> wrote:
> > Random thoughts:
> >
> > - swsusp has been a multi-year ongoing source of churn and bug reports.
> > It hasn't been a big success and we have a way to go yet.
>
> swsusp may be an ongoing source of churn and bug reports, but it's
> also been more reliable for me (on multiple types of hardware) than
> Windows XP hibernate. In fact, at this point I'm perfectly satisfied
> with its reliability (i.e. I haven't had any problems lately).
>
> (I just figure that I need to speak up, as a highly satisfied swsusp user.)
Thanks! :-)
Rafael
Hi,
On Saturday 04 February 2006 10:54, Nigel Cunningham wrote:
> On Saturday 04 February 2006 19:01, Pavel Machek wrote:
> > On So 04-02-06 11:20:54, Nigel Cunningham wrote:
> > > Hi Pavel.
> > >
> > > On Friday 03 February 2006 21:44, Pavel Machek wrote:
> > > > [Pavel is willing to take patches, as his cooperation with Rafael
> > > > shows, but is scared by both big patches and series of 10 small
> > > > patches he does not understand. He likes patches removing code.]
> > >
> > > Assuming you're refering to the patches that started this thread, what
> > > don't you understand? I'm more than happy to explain.
> >
> > For "suspend2: modules support", it is pretty clear that I do not need
> > or want that complexity. But for "refrigerator improvements", I did
>
> ... and yet you're perfectly happy to add the complexity of sticking half
> the code in userspace. I don't think I'll ever dare to try to understand
> you, Pavel :)
>
> > not understand which parts are neccessary because of suspend2
> > vs. swsusp differences, and if there is simpler way towards the same
> > goal. (And thanks for a stress hint...)
>
> I think virtually everything is relevant to you.
My personal view is that:
1) turning the freezing of kernel threads upside-down is not necessary and
would cause problems in the long run,
2) the todo lists are not necessary and add a lot of complexity,
3) trying to treat uninterruptible tasks as non-freezeable should better be
avoided (I tried to implement this in swsusp last year but it caused vigorous
opposition to appear, and it was not Pavel ;-))
> A couple of possible exceptions might be (1) freezing bdevs,
> because you don't care so much about making xfs really sync and really
> stop it's activity
As I have already stated, in my view this one is at least worth considering
in the long run.
> and (2) the ability to thaw kernel space without thawing userspace. I want
> this for eating memory, to avoid deadlocking against kjournald etc. I haven't
> checked carefully as to why you don't need it in vanilla.
Because it does not deadlock? I will say we need this if I see a testcase
showing such a deadlock clearly.
Greetings,
Rafael
Hi.
On Saturday 04 February 2006 20:58, Rafael J. Wysocki wrote:
> Hi,
>
> On Saturday 04 February 2006 10:54, Nigel Cunningham wrote:
> > On Saturday 04 February 2006 19:01, Pavel Machek wrote:
> > > On So 04-02-06 11:20:54, Nigel Cunningham wrote:
> > > > Hi Pavel.
> > > >
> > > > On Friday 03 February 2006 21:44, Pavel Machek wrote:
> > > > > [Pavel is willing to take patches, as his cooperation with
> > > > > Rafael shows, but is scared by both big patches and series of 10
> > > > > small patches he does not understand. He likes patches removing
> > > > > code.]
> > > >
> > > > Assuming you're refering to the patches that started this thread,
> > > > what don't you understand? I'm more than happy to explain.
> > >
> > > For "suspend2: modules support", it is pretty clear that I do not
> > > need or want that complexity. But for "refrigerator improvements", I
> > > did
> >
> > ... and yet you're perfectly happy to add the complexity of sticking
> > half the code in userspace. I don't think I'll ever dare to try to
> > understand you, Pavel :)
> >
> > > not understand which parts are neccessary because of suspend2
> > > vs. swsusp differences, and if there is simpler way towards the same
> > > goal. (And thanks for a stress hint...)
> >
> > I think virtually everything is relevant to you.
>
> My personal view is that:
> 1) turning the freezing of kernel threads upside-down is not necessary
> and would cause problems in the long run,
Upside down?
> 2) the todo lists are not necessary and add a lot of complexity,
Sorry. Forgot about this. I liked it for solving the SMP problem, but IIRC,
we're downing other cpus before this now, so that issue has gone away. I
should check whether I'm right there.
> 3) trying to treat uninterruptible tasks as non-freezeable should better
> be avoided (I tried to implement this in swsusp last year but it caused
> vigorous opposition to appear, and it was not Pavel ;-))
I'm not suggesting treating them as unfreezeable in the fullest sense. I
still signal them, but don't mind if they don't respond. This way, if they
do leave that state for some reason (timeout?) at some point, they still
get frozen.
> > A couple of possible exceptions might be (1) freezing bdevs,
> > because you don't care so much about making xfs really sync and really
> > stop it's activity
>
> As I have already stated, in my view this one is at least worth
> considering in the long run.
>
> > and (2) the ability to thaw kernel space without thawing userspace. I
> > want this for eating memory, to avoid deadlocking against kjournald
> > etc. I haven't checked carefully as to why you don't need it in
> > vanilla.
>
> Because it does not deadlock? I will say we need this if I see a
> testcase showing such a deadlock clearly.
I've been surprised that you haven't already seen them while eating memory
such that filesystems come into play. Perhaps you guys only use swap
partitions, and something like a swapfile with some memory pressure might
trigger this? Or it could be a side effect of one of the other changes.
Nigel
> Greetings,
> Rafael
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi,
On Saturday 04 February 2006 12:08, Nigel Cunningham wrote:
> On Saturday 04 February 2006 20:58, Rafael J. Wysocki wrote:
> > Hi,
> >
> > On Saturday 04 February 2006 10:54, Nigel Cunningham wrote:
> > > On Saturday 04 February 2006 19:01, Pavel Machek wrote:
> > > > On So 04-02-06 11:20:54, Nigel Cunningham wrote:
> > > > > Hi Pavel.
> > > > >
> > > > > On Friday 03 February 2006 21:44, Pavel Machek wrote:
> > > > > > [Pavel is willing to take patches, as his cooperation with
> > > > > > Rafael shows, but is scared by both big patches and series of 10
> > > > > > small patches he does not understand. He likes patches removing
> > > > > > code.]
> > > > >
> > > > > Assuming you're refering to the patches that started this thread,
> > > > > what don't you understand? I'm more than happy to explain.
> > > >
> > > > For "suspend2: modules support", it is pretty clear that I do not
> > > > need or want that complexity. But for "refrigerator improvements", I
> > > > did
> > >
> > > ... and yet you're perfectly happy to add the complexity of sticking
> > > half the code in userspace. I don't think I'll ever dare to try to
> > > understand you, Pavel :)
> > >
> > > > not understand which parts are neccessary because of suspend2
> > > > vs. swsusp differences, and if there is simpler way towards the same
> > > > goal. (And thanks for a stress hint...)
> > >
> > > I think virtually everything is relevant to you.
> >
> > My personal view is that:
> > 1) turning the freezing of kernel threads upside-down is not necessary
> > and would cause problems in the long run,
>
> Upside down?
I mean now they should freeze voluntarily and your patches change that
so they would have to be created as non-freezeable if need be, AFAICT.
> > 2) the todo lists are not necessary and add a lot of complexity,
>
> Sorry. Forgot about this. I liked it for solving the SMP problem, but IIRC,
> we're downing other cpus before this now, so that issue has gone away. I
> should check whether I'm right there.
>
> > 3) trying to treat uninterruptible tasks as non-freezeable should better
> > be avoided (I tried to implement this in swsusp last year but it caused
> > vigorous opposition to appear, and it was not Pavel ;-))
>
> I'm not suggesting treating them as unfreezeable in the fullest sense. I
> still signal them, but don't mind if they don't respond. This way, if they
> do leave that state for some reason (timeout?) at some point, they still
> get frozen.
Yes, that's exactly what I wanted to do in swsusp. ;-)
> > > A couple of possible exceptions might be (1) freezing bdevs,
> > > because you don't care so much about making xfs really sync and really
> > > stop it's activity
> >
> > As I have already stated, in my view this one is at least worth
> > considering in the long run.
> >
> > > and (2) the ability to thaw kernel space without thawing userspace. I
> > > want this for eating memory, to avoid deadlocking against kjournald
> > > etc. I haven't checked carefully as to why you don't need it in
> > > vanilla.
> >
> > Because it does not deadlock? I will say we need this if I see a
> > testcase showing such a deadlock clearly.
>
> I've been surprised that you haven't already seen them while eating memory
> such that filesystems come into play. Perhaps you guys only use swap
> partitions, and something like a swapfile with some memory pressure might
> trigger this? Or it could be a side effect of one of the other changes.
In fact, we only use swap partitions, so this will be needed if we are going
to use files, I guess. Nice to know in advance, thanks. ;-)
Greetings,
Rafael
Hi.
On Saturday 04 February 2006 21:38, Rafael J. Wysocki wrote:
> > > My personal view is that:
> > > 1) turning the freezing of kernel threads upside-down is not
> > > necessary and would cause problems in the long run,
> >
> > Upside down?
>
> I mean now they should freeze voluntarily and your patches change that
> so they would have to be created as non-freezeable if need be, AFAICT.
Ah. Now I'm on the same page. Lost the context.
> > > 2) the todo lists are not necessary and add a lot of complexity,
> >
> > Sorry. Forgot about this. I liked it for solving the SMP problem, but
> > IIRC, we're downing other cpus before this now, so that issue has gone
> > away. I should check whether I'm right there.
> >
> > > 3) trying to treat uninterruptible tasks as non-freezeable should
> > > better be avoided (I tried to implement this in swsusp last year but
> > > it caused vigorous opposition to appear, and it was not Pavel ;-))
> >
> > I'm not suggesting treating them as unfreezeable in the fullest sense.
> > I still signal them, but don't mind if they don't respond. This way,
> > if they do leave that state for some reason (timeout?) at some point,
> > they still get frozen.
>
> Yes, that's exactly what I wanted to do in swsusp. ;-)
Oh. What's Pavel's solution? Fail freezing if uninterruptible threads don't
freeze?
> > > > A couple of possible exceptions might be (1) freezing bdevs,
> > > > because you don't care so much about making xfs really sync and
> > > > really stop it's activity
> > >
> > > As I have already stated, in my view this one is at least worth
> > > considering in the long run.
> > >
> > > > and (2) the ability to thaw kernel space without thawing
> > > > userspace. I want this for eating memory, to avoid deadlocking
> > > > against kjournald etc. I haven't checked carefully as to why you
> > > > don't need it in vanilla.
> > >
> > > Because it does not deadlock? I will say we need this if I see a
> > > testcase showing such a deadlock clearly.
> >
> > I've been surprised that you haven't already seen them while eating
> > memory such that filesystems come into play. Perhaps you guys only use
> > swap partitions, and something like a swapfile with some memory
> > pressure might trigger this? Or it could be a side effect of one of
> > the other changes.
>
> In fact, we only use swap partitions, so this will be needed if we are
> going to use files, I guess. Nice to know in advance, thanks. ;-)
k. Just so you don't confuse me, can I ask you not to refer to swapfiles as
'files'? I support swap partitions, swapfiles and ordinary files, so the
latter will come to mind first for me.
Regards,
Nigel
> Greetings,
> Rafael
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi,
On Saturday 04 February 2006 12:41, Nigel Cunningham wrote:
> On Saturday 04 February 2006 21:38, Rafael J. Wysocki wrote:
> > > > My personal view is that:
> > > > 1) turning the freezing of kernel threads upside-down is not
> > > > necessary and would cause problems in the long run,
> > >
> > > Upside down?
> >
> > I mean now they should freeze voluntarily and your patches change that
> > so they would have to be created as non-freezeable if need be, AFAICT.
>
> Ah. Now I'm on the same page. Lost the context.
>
> > > > 2) the todo lists are not necessary and add a lot of complexity,
> > >
> > > Sorry. Forgot about this. I liked it for solving the SMP problem, but
> > > IIRC, we're downing other cpus before this now, so that issue has gone
> > > away. I should check whether I'm right there.
> > >
> > > > 3) trying to treat uninterruptible tasks as non-freezeable should
> > > > better be avoided (I tried to implement this in swsusp last year but
> > > > it caused vigorous opposition to appear, and it was not Pavel ;-))
> > >
> > > I'm not suggesting treating them as unfreezeable in the fullest sense.
> > > I still signal them, but don't mind if they don't respond. This way,
> > > if they do leave that state for some reason (timeout?) at some point,
> > > they still get frozen.
> >
> > Yes, that's exactly what I wanted to do in swsusp. ;-)
>
> Oh. What's Pavel's solution? Fail freezing if uninterruptible threads don't
> freeze?
>
> > > > > A couple of possible exceptions might be (1) freezing bdevs,
> > > > > because you don't care so much about making xfs really sync and
> > > > > really stop it's activity
> > > >
> > > > As I have already stated, in my view this one is at least worth
> > > > considering in the long run.
> > > >
> > > > > and (2) the ability to thaw kernel space without thawing
> > > > > userspace. I want this for eating memory, to avoid deadlocking
> > > > > against kjournald etc. I haven't checked carefully as to why you
> > > > > don't need it in vanilla.
> > > >
> > > > Because it does not deadlock? I will say we need this if I see a
> > > > testcase showing such a deadlock clearly.
> > >
> > > I've been surprised that you haven't already seen them while eating
> > > memory such that filesystems come into play. Perhaps you guys only use
> > > swap partitions, and something like a swapfile with some memory
> > > pressure might trigger this? Or it could be a side effect of one of
> > > the other changes.
> >
> > In fact, we only use swap partitions, so this will be needed if we are
> > going to use files, I guess. Nice to know in advance, thanks. ;-)
>
> k. Just so you don't confuse me, can I ask you not to refer to swapfiles as
> 'files'? I support swap partitions, swapfiles and ordinary files, so the
> latter will come to mind first for me.
Sure. In fact I was referring to both swapfiles and regular files as just
"files".
Greetings,
Rafael
Hi,
On Saturday 04 February 2006 02:23, Pavel Machek wrote:
> On So 04-02-06 02:08:33, Olivier Galibert wrote:
> > On Sat, Feb 04, 2006 at 01:49:44AM +0100, Pavel Machek wrote:
> > > > Why don't you try to design the system so that the progress bar can't
> > > > fuck up the suspend unless they really, really want to? Instead of
> > > > one where a forgotten open(O_CREAT) in a corner of graphics code can
> > > > randomly trash the filesystem through metadata corruption?
> > >
> > > Even if I only put chrome code to userspace, open() would still be
> > > deadly. I could do something fancy with disallowing syscalls,
> >
> > Nah, simply chroot to an empty virtual filesystem (a tmpfs with max
> > size=0 will do) and they can't do any fs-related fuckup anymore. Just
> > give them a fd through which request some specific resources
> > (framebuffer mmap essentially I would say) and exchange messages with
> > the suspend system (status, cancel, etc) and maybe log stderr for
> > debugging purposes and that's it. They can't do damage by mistake
> > anymore. They can always send signals to random pids, but that's not
> > called a mistake at that point.
> >
> > Even better, you can run _multiple_ processes that way, some for
> > compression/encryption, some for chrome, etc.
>
> No, I do not want to deal with multiple processes. Chrome code is not
> *as* evil as you paint it... But yes, chroot is a nice idea. Doing
> chroot into nowhere after freezing system will prevent most stupid
> mistakes. Rest of userland is frozen, so it can not do anything really
> wrong (at most you deadlock), if you kill someone -- well, that's only
> as dangerous as any other code running as root.
I like the chroot idea too.
Are we going to chroot from the kernel level (eg. the atomic snapshot
ioctl()) or from within the suspending utility?
I think the kernel level would protect some people from bugs in their own
suspending utilities, but then we'd have to mount the tmpfs from the kernel
level as well.
Greetings,
Rafael
Hi,
On Saturday 04 February 2006 12:41, Nigel Cunningham wrote:
> On Saturday 04 February 2006 21:38, Rafael J. Wysocki wrote:
> > > > My personal view is that:
> > > > 1) turning the freezing of kernel threads upside-down is not
> > > > necessary and would cause problems in the long run,
> > >
> > > Upside down?
> >
> > I mean now they should freeze voluntarily and your patches change that
> > so they would have to be created as non-freezeable if need be, AFAICT.
>
> Ah. Now I'm on the same page. Lost the context.
>
> > > > 2) the todo lists are not necessary and add a lot of complexity,
> > >
> > > Sorry. Forgot about this. I liked it for solving the SMP problem, but
> > > IIRC, we're downing other cpus before this now, so that issue has gone
> > > away. I should check whether I'm right there.
> > >
> > > > 3) trying to treat uninterruptible tasks as non-freezeable should
> > > > better be avoided (I tried to implement this in swsusp last year but
> > > > it caused vigorous opposition to appear, and it was not Pavel ;-))
> > >
> > > I'm not suggesting treating them as unfreezeable in the fullest sense.
> > > I still signal them, but don't mind if they don't respond. This way,
> > > if they do leave that state for some reason (timeout?) at some point,
> > > they still get frozen.
> >
> > Yes, that's exactly what I wanted to do in swsusp. ;-)
>
> Oh. What's Pavel's solution? Fail freezing if uninterruptible threads don't
> freeze?
Yes.
AFAICT it's to avoid situations in which we would freeze having a
process in the D state that holds a semaphore or a mutex neded for
suspending or resuming devices (or later on for saving the image etc.).
[I didn't answer this question previously, sorry.]
Greetings,
Rafael
Hi!
> > > 3) trying to treat uninterruptible tasks as non-freezeable should better
> > > be avoided (I tried to implement this in swsusp last year but it caused
> > > vigorous opposition to appear, and it was not Pavel ;-))
> >
> > I'm not suggesting treating them as unfreezeable in the fullest sense. I
> > still signal them, but don't mind if they don't respond. This way, if they
> > do leave that state for some reason (timeout?) at some point, they still
> > get frozen.
>
> Yes, that's exactly what I wanted to do in swsusp. ;-)
It seems dangerous to me. Imagine you treated interruptible tasks like
that...
What prevent task from doing
set_state(UNINTERRUPTIBLE);
schedule(one hour);
write_to_filesystem();
handle_signal()?
I.e. it may do something dangerous just before being catched by
refrigerator.
Pavel
--
Thanks, Sharp!
Hi!
> > No, I do not want to deal with multiple processes. Chrome code is not
> > *as* evil as you paint it... But yes, chroot is a nice idea. Doing
> > chroot into nowhere after freezing system will prevent most stupid
> > mistakes. Rest of userland is frozen, so it can not do anything really
> > wrong (at most you deadlock), if you kill someone -- well, that's only
> > as dangerous as any other code running as root.
>
> I like the chroot idea too.
>
> Are we going to chroot from the kernel level (eg. the atomic snapshot
> ioctl()) or from within the suspending utility?
>
> I think the kernel level would protect some people from bugs in their own
> suspending utilities, but then we'd have to mount the tmpfs from the kernel
> level as well.
What about this (untested)?
BTW we do some playing with consoles after freeze. Would it be
possible to do it *before* freeze? Opening tty might change its
access time...?
Pavel
Index: resume.c
===================================================================
RCS file: /cvsroot/suspend/suspend/resume.c,v
retrieving revision 1.4
diff -u -u -r1.4 resume.c
--- resume.c 3 Feb 2006 22:39:24 -0000 1.4
+++ resume.c 4 Feb 2006 19:19:48 -0000
@@ -227,6 +227,12 @@
error = errno;
goto Close;
}
+ /*
+ * From now on, system is frozen; any filesystem access may mean data corruption.
+ * Prevent accidental filesystem accesses by chrooting somewhere where little
+ * damage can be done.
+ */
+ chroot("/sys/power");
atomic_restore(dev);
unfreeze(dev);
Close:
Index: suspend.c
===================================================================
RCS file: /cvsroot/suspend/suspend/suspend.c,v
retrieving revision 1.5
diff -u -u -r1.5 suspend.c
--- suspend.c 3 Feb 2006 22:39:24 -0000 1.5
+++ suspend.c 4 Feb 2006 19:19:51 -0000
@@ -360,6 +360,12 @@
goto Close;
}
go_to_console();
+ /*
+ * From now on, system is frozen; any filesystem access may mean data corruption.
+ * Prevent accidental filesystem accesses by chrooting somewhere where little
+ * damage can be done.
+ */
+ chroot("/sys/power");
attempts = 2;
do {
if (set_image_size(dev, image_size)) {
--
Thanks, Sharp!
Hi!
> > > > [Pavel is willing to take patches, as his cooperation with Rafael
> > > > shows, but is scared by both big patches and series of 10 small
> > > > patches he does not understand. He likes patches removing code.]
> > >
> > > Assuming you're refering to the patches that started this thread, what
> > > don't you understand? I'm more than happy to explain.
> >
> > For "suspend2: modules support", it is pretty clear that I do not need
> > or want that complexity. But for "refrigerator improvements", I did
>
> ... and yet you're perfectly happy to add the complexity of sticking half
> the code in userspace. I don't think I'll ever dare to try to understand
> you, Pavel :)
Complexity in userspace: ungood.
Complexity in kernel: doubleplusungood.
It is not that hard to understand :-).
Pavel
--
Thanks, Sharp!
Hi,
On Saturday 04 February 2006 20:21, Pavel Machek wrote:
> > > No, I do not want to deal with multiple processes. Chrome code is not
> > > *as* evil as you paint it... But yes, chroot is a nice idea. Doing
> > > chroot into nowhere after freezing system will prevent most stupid
> > > mistakes. Rest of userland is frozen, so it can not do anything really
> > > wrong (at most you deadlock), if you kill someone -- well, that's only
> > > as dangerous as any other code running as root.
> >
> > I like the chroot idea too.
> >
> > Are we going to chroot from the kernel level (eg. the atomic snapshot
> > ioctl()) or from within the suspending utility?
> >
> > I think the kernel level would protect some people from bugs in their own
> > suspending utilities, but then we'd have to mount the tmpfs from the kernel
> > level as well.
>
> What about this (untested)?
So you think we should chroot from the user space. Fine.
> BTW we do some playing with consoles after freeze. Would it be
> possible to do it *before* freeze? Opening tty might change its
> access time...?
Yes, you are right, but please see below.
> Index: resume.c
> ===================================================================
> RCS file: /cvsroot/suspend/suspend/resume.c,v
> retrieving revision 1.4
> diff -u -u -r1.4 resume.c
> --- resume.c 3 Feb 2006 22:39:24 -0000 1.4
> +++ resume.c 4 Feb 2006 19:19:48 -0000
> @@ -227,6 +227,12 @@
> error = errno;
> goto Close;
> }
> + /*
> + * From now on, system is frozen; any filesystem access may mean data corruption.
> + * Prevent accidental filesystem accesses by chrooting somewhere where little
> + * damage can be done.
> + */
> + chroot("/sys/power");
We are on an initrd here. :-)
> atomic_restore(dev);
> unfreeze(dev);
> Close:
> Index: suspend.c
> ===================================================================
> RCS file: /cvsroot/suspend/suspend/suspend.c,v
> retrieving revision 1.5
> diff -u -u -r1.5 suspend.c
> --- suspend.c 3 Feb 2006 22:39:24 -0000 1.5
> +++ suspend.c 4 Feb 2006 19:19:51 -0000
> @@ -360,6 +360,12 @@
> goto Close;
> }
> go_to_console();
> + /*
> + * From now on, system is frozen; any filesystem access may mean data corruption.
> + * Prevent accidental filesystem accesses by chrooting somewhere where little
> + * damage can be done.
> + */
> + chroot("/sys/power");
This won't be enough if /sys/power is on a frozen ext2 and the suspending
utility calls open("file", O_CREAT) "by accident".
I think we should do as Olivier said: Mount tmpfs with limited size somewhere
and chroot to it (IMO this won't affect the underlying filesystem). Then, create
device files for the console and vt on it and open them from there. This should
be 100% safe.
Greetings,
Rafael
Hi!
> > > Are we going to chroot from the kernel level (eg. the atomic snapshot
> > > ioctl()) or from within the suspending utility?
> > >
> > > I think the kernel level would protect some people from bugs in their own
> > > suspending utilities, but then we'd have to mount the tmpfs from the kernel
> > > level as well.
> >
> > What about this (untested)?
>
> So you think we should chroot from the user space. Fine.
Yes, sorry that I was not explicit.
> > }
> > + /*
> > + * From now on, system is frozen; any filesystem access may mean data corruption.
> > + * Prevent accidental filesystem accesses by chrooting somewhere where little
> > + * damage can be done.
> > + */
> > + chroot("/sys/power");
>
> We are on an initrd here. :-)
Oops, right, forget that.
> > Index: suspend.c
> > ===================================================================
> > RCS file: /cvsroot/suspend/suspend/suspend.c,v
> > retrieving revision 1.5
> > diff -u -u -r1.5 suspend.c
> > --- suspend.c 3 Feb 2006 22:39:24 -0000 1.5
> > +++ suspend.c 4 Feb 2006 19:19:51 -0000
> > @@ -360,6 +360,12 @@
> > goto Close;
> > }
> > go_to_console();
> > + /*
> > + * From now on, system is frozen; any filesystem access may mean data corruption.
> > + * Prevent accidental filesystem accesses by chrooting somewhere where little
> > + * damage can be done.
> > + */
> > + chroot("/sys/power");
>
> This won't be enough if /sys/power is on a frozen ext2 and the suspending
> utility calls open("file", O_CREAT) "by accident".
...well, we rely on sysfs files to work... at least for
suspend-to-RAM, ok, no argument here. I doubt anyone really does mount
anything but sysfs on /sys...
> I think we should do as Olivier said: Mount tmpfs with limited size somewhere
> and chroot to it (IMO this won't affect the underlying filesystem). Then, create
> device files for the console and vt on it and open them from there. This should
> be 100% safe.
Looks unneccessarily complex to me. We'd have to umount that tmpfs,
and playing with mounts inside system suspend seems wrong to me.
Perhaps we can chroot into /proc... almost everyone has /proc
mounted, right?
Is it possible to move console/vt open before freeze? That should be
enough.
Pavel
--
Thanks, Sharp!
Hi,
On Saturday 04 February 2006 21:15, Pavel Machek wrote:
}-- snip --{
> > > Index: suspend.c
> > > ===================================================================
> > > RCS file: /cvsroot/suspend/suspend/suspend.c,v
> > > retrieving revision 1.5
> > > diff -u -u -r1.5 suspend.c
> > > --- suspend.c 3 Feb 2006 22:39:24 -0000 1.5
> > > +++ suspend.c 4 Feb 2006 19:19:51 -0000
> > > @@ -360,6 +360,12 @@
> > > goto Close;
> > > }
> > > go_to_console();
> > > + /*
> > > + * From now on, system is frozen; any filesystem access may mean data corruption.
> > > + * Prevent accidental filesystem accesses by chrooting somewhere where little
> > > + * damage can be done.
> > > + */
> > > + chroot("/sys/power");
> >
> > This won't be enough if /sys/power is on a frozen ext2 and the suspending
> > utility calls open("file", O_CREAT) "by accident".
>
> ...well, we rely on sysfs files to work... at least for
> suspend-to-RAM, ok, no argument here. I doubt anyone really does mount
> anything but sysfs on /sys...
>
> > I think we should do as Olivier said: Mount tmpfs with limited size somewhere
> > and chroot to it (IMO this won't affect the underlying filesystem). Then, create
> > device files for the console and vt on it and open them from there. This should
> > be 100% safe.
>
> Looks unneccessarily complex to me. We'd have to umount that tmpfs,
> and playing with mounts inside system suspend seems wrong to me.
>
> Perhaps we can chroot into /proc... almost everyone has /proc
> mounted, right?
>
> Is it possible to move console/vt open before freeze?
No, because freeze sets the active vt for us. How about that: mount the
tmpfs before freeze, put there what we'll need, open device files from
there instead of /dev, and chroot() after atomic_snapshot? Then, after
resume we won't be chrooted and we'll be able to unmount the tmpfs
safely.
Greetings,
Rafael
Hi.
On Saturday 04 February 2006 23:51, Rafael J. Wysocki wrote:
> Hi,
>
> On Saturday 04 February 2006 02:23, Pavel Machek wrote:
> > On So 04-02-06 02:08:33, Olivier Galibert wrote:
> > > On Sat, Feb 04, 2006 at 01:49:44AM +0100, Pavel Machek wrote:
> > > > > Why don't you try to design the system so that the progress bar
> > > > > can't fuck up the suspend unless they really, really want to?
> > > > > Instead of one where a forgotten open(O_CREAT) in a corner of
> > > > > graphics code can randomly trash the filesystem through metadata
> > > > > corruption?
> > > >
> > > > Even if I only put chrome code to userspace, open() would still be
> > > > deadly. I could do something fancy with disallowing syscalls,
> > >
> > > Nah, simply chroot to an empty virtual filesystem (a tmpfs with max
> > > size=0 will do) and they can't do any fs-related fuckup anymore.
> > > Just give them a fd through which request some specific resources
> > > (framebuffer mmap essentially I would say) and exchange messages
> > > with the suspend system (status, cancel, etc) and maybe log stderr
> > > for debugging purposes and that's it. They can't do damage by
> > > mistake anymore. They can always send signals to random pids, but
> > > that's not called a mistake at that point.
> > >
> > > Even better, you can run _multiple_ processes that way, some for
> > > compression/encryption, some for chrome, etc.
> >
> > No, I do not want to deal with multiple processes. Chrome code is not
> > *as* evil as you paint it... But yes, chroot is a nice idea. Doing
> > chroot into nowhere after freezing system will prevent most stupid
> > mistakes. Rest of userland is frozen, so it can not do anything really
> > wrong (at most you deadlock), if you kill someone -- well, that's only
> > as dangerous as any other code running as root.
>
> I like the chroot idea too.
You're making this too complicated. Just require that the userspace program
does all it's file opening etc prior to telling kernelspace to do
anything. Then clearly document the requirement. If someone breaks the
rule, it is their problem, and their testing should show their
foolishness. We have done a similar thing in the Suspend2 userspace user
interface code, and it works fine.
Regards,
Nigel
> Are we going to chroot from the kernel level (eg. the atomic snapshot
> ioctl()) or from within the suspending utility?
>
> I think the kernel level would protect some people from bugs in their
> own suspending utilities, but then we'd have to mount the tmpfs from the
> kernel level as well.
>
> Greetings,
> Rafael
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Hi.
On Sunday 05 February 2006 03:18, Rafael J. Wysocki wrote:
> Hi,
>
> On Saturday 04 February 2006 12:41, Nigel Cunningham wrote:
> > On Saturday 04 February 2006 21:38, Rafael J. Wysocki wrote:
> > > > > My personal view is that:
> > > > > 1) turning the freezing of kernel threads upside-down is not
> > > > > necessary and would cause problems in the long run,
> > > >
> > > > Upside down?
> > >
> > > I mean now they should freeze voluntarily and your patches change
> > > that so they would have to be created as non-freezeable if need be,
> > > AFAICT.
> >
> > Ah. Now I'm on the same page. Lost the context.
> >
> > > > > 2) the todo lists are not necessary and add a lot of complexity,
> > > >
> > > > Sorry. Forgot about this. I liked it for solving the SMP problem,
> > > > but IIRC, we're downing other cpus before this now, so that issue
> > > > has gone away. I should check whether I'm right there.
> > > >
> > > > > 3) trying to treat uninterruptible tasks as non-freezeable
> > > > > should better be avoided (I tried to implement this in swsusp
> > > > > last year but it caused vigorous opposition to appear, and it
> > > > > was not Pavel ;-))
> > > >
> > > > I'm not suggesting treating them as unfreezeable in the fullest
> > > > sense. I still signal them, but don't mind if they don't respond.
> > > > This way, if they do leave that state for some reason (timeout?)
> > > > at some point, they still get frozen.
> > >
> > > Yes, that's exactly what I wanted to do in swsusp. ;-)
> >
> > Oh. What's Pavel's solution? Fail freezing if uninterruptible threads
> > don't freeze?
>
> Yes.
>
> AFAICT it's to avoid situations in which we would freeze having a
> process in the D state that holds a semaphore or a mutex neded for
> suspending or resuming devices (or later on for saving the image etc.).
>
> [I didn't answer this question previously, sorry.]
S'okay. This thread is an ocotpus :)
Are there real life examples of this? I can't think of a single time that
I've heard of something like this happening. I do see rare problems with
storage drivers not having driver model support right, and thereby causing
hangs, but that's brokenness in a completely different way.
In short, I'm wondering if (apart from the forking issue), this is a straw
man.
Regards,
Nigel
> Greetings,
> Rafael
>
> _______________________________________________
> Suspend2-devel mailing list
> [email protected]
> http://lists.suspend2.net/mailman/listinfo/suspend2-devel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Sunday 05 February 2006 05:10, Pavel Machek wrote:
> Hi!
>
> > > > 3) trying to treat uninterruptible tasks as non-freezeable should
> > > > better be avoided (I tried to implement this in swsusp last year
> > > > but it caused vigorous opposition to appear, and it was not Pavel
> > > > ;-))
> > >
> > > I'm not suggesting treating them as unfreezeable in the fullest
> > > sense. I still signal them, but don't mind if they don't respond.
> > > This way, if they do leave that state for some reason (timeout?) at
> > > some point, they still get frozen.
> >
> > Yes, that's exactly what I wanted to do in swsusp. ;-)
>
> It seems dangerous to me. Imagine you treated interruptible tasks like
> that...
>
> What prevent task from doing
>
> set_state(UNINTERRUPTIBLE);
> schedule(one hour);
> write_to_filesystem();
> handle_signal()?
>
> I.e. it may do something dangerous just before being catched by
> refrigerator.
The write_to_filesystem would be caught be bdev freezing if you had it.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi,
On Monday 06 February 2006 00:43, Nigel Cunningham wrote:
> On Sunday 05 February 2006 03:18, Rafael J. Wysocki wrote:
> > On Saturday 04 February 2006 12:41, Nigel Cunningham wrote:
> > > On Saturday 04 February 2006 21:38, Rafael J. Wysocki wrote:
> > > > > > My personal view is that:
> > > > > > 1) turning the freezing of kernel threads upside-down is not
> > > > > > necessary and would cause problems in the long run,
> > > > >
> > > > > Upside down?
> > > >
> > > > I mean now they should freeze voluntarily and your patches change
> > > > that so they would have to be created as non-freezeable if need be,
> > > > AFAICT.
> > >
> > > Ah. Now I'm on the same page. Lost the context.
> > >
> > > > > > 2) the todo lists are not necessary and add a lot of complexity,
> > > > >
> > > > > Sorry. Forgot about this. I liked it for solving the SMP problem,
> > > > > but IIRC, we're downing other cpus before this now, so that issue
> > > > > has gone away. I should check whether I'm right there.
> > > > >
> > > > > > 3) trying to treat uninterruptible tasks as non-freezeable
> > > > > > should better be avoided (I tried to implement this in swsusp
> > > > > > last year but it caused vigorous opposition to appear, and it
> > > > > > was not Pavel ;-))
> > > > >
> > > > > I'm not suggesting treating them as unfreezeable in the fullest
> > > > > sense. I still signal them, but don't mind if they don't respond.
> > > > > This way, if they do leave that state for some reason (timeout?)
> > > > > at some point, they still get frozen.
> > > >
> > > > Yes, that's exactly what I wanted to do in swsusp. ;-)
> > >
> > > Oh. What's Pavel's solution? Fail freezing if uninterruptible threads
> > > don't freeze?
> >
> > Yes.
> >
> > AFAICT it's to avoid situations in which we would freeze having a
> > process in the D state that holds a semaphore or a mutex neded for
> > suspending or resuming devices (or later on for saving the image etc.).
> >
> > [I didn't answer this question previously, sorry.]
>
> S'okay. This thread is an ocotpus :)
>
> Are there real life examples of this? I can't think of a single time that
> I've heard of something like this happening. I do see rare problems with
> storage drivers not having driver model support right, and thereby causing
> hangs, but that's brokenness in a completely different way.
>
> In short, I'm wondering if (apart from the forking issue), this is a straw
> man.
It doesn't seem to be very probable to me too, but I take this argument
as valid.
Greetings,
Rafael
Hi.
On Sunday 05 February 2006 05:29, Pavel Machek wrote:
> Complexity in userspace: ungood.
>
> Complexity in kernel: doubleplusungood.
>
> It is not that hard to understand :-).
Heh. you'll soon be submitting patches to move interrupt handling and
scheduling to userspace then?
Seriously, though, thanks for the opportunity to explain how Suspend2 works
and show that it's not complex, and simpler than what you're going to end
up with if you continue down the userspace track and seek to match
Suspend2 in functionaltiy (apples for apples would be the fairest
comparison, so that's what I'm aiming for here).
I've downloaded Rafael's userspace files and the latest mm, and used them
to figure out how userspace swsusp works as you have it at the moment.
>From there, I've extended the analogy to try to include the extra
functionality you're talking about implementing. Feel free to correct
misunderstandings or wrong assumptions :)
a. Freezing processes, freeing memory and preparing the image.
Freezing processes maps nice and cleanly to userspace because the kernel
still does all the work. Extra ioctls to freeze and thaw other processes
are all that's needed. There is no serious possibility of moving more of
the work of freezing processes to userspace.
Freeing memory and preparing the image is significantly simpler for swsusp
at the moment because it doesn't support swap files, and doesn't worry so
much about being reliable under memory and process load. If this was to
change, swsusp would probably want more of the modifications to the
freezer that suspend2 includes, particularly the ability to thaw just the
kernel threads. When userspace is being memory hungry and/or processor
intensive, being able to thaw just the kernel threads helps a lot, because
we can then put pressure on the VM without worry about deadlocking against
frozen filesystems or racing against userspace processes that are grabbing
memory and/or processor while we're trying to meet our constraints on
memory and storage.
c. Compression and encryption.
The current implementation has no direct support for compressing,
encrypting or otherwise transforming the data to be written. This could
never-the-less be achieved by writing to a device that was configured
using the standard support, and reconfiguring access to the
compressed/encrypted devices before reading the image at resume time.
Adding support for compressing and/or encrypting an image from within
uswsusp would presumably require adding dependencies upon existing
libraries or using cryptoapi functions via ioctls or such like. Making
such support optional and configurable would require further modification.
Using userspace libraries for compression and encryption would increase
the complexity of configuring uswsusp for a developer (extra packages to
download/configure/install), and create greater potential for support
issues for developers and distributions (uswusp gets blamed for any
problems in those libraries but can't do anything to fix them!).
If any flexibility was going to be allowed in methods of encrypting and
compressing the image, a standardised interface would need to be
developed. This interface would almost certainly be approximately
equivalent
Back in the days of Suspend1, or maybe before, I had compression code
inlined in the read/write-a-page loop. Based on my experience in having
implemented the modular architecture, changing the compression method from
gzip to lzf and then to cryptoapi support, I can't see how you'd want to
to hardwire this. (Besides, with the modular architecture, CONFIG_SUSPEND2
+ !CONFIG_CRYPTOAPI is really simple - we just don't compile in the
compression and encryption modules).
d. Storage of the image.
As it currently stands, the interface between userspace and the kernel for
uswsusp looks clean and simple. This is mainly, however, because it only
supports writing to swap, and strictly synchronously.
If you were going to match the functionality in suspend2, you would be
looking at adding support for (a) asynchronous I/O, (b) for ordinary
files, (c) for multiple swap devices (d) for swapfiles and (e) for the
varying blocksizes of filesystems. I assume uswsusp won't currently work
with swapfiles (as opposed to swap partitions) as it stands because I see
a check for !S_ISBLK(resume_device) in suspend.c::main.
The simplest way I can see to achieve parity of functionality would be to
treat all storage as a lists of sectors on bdevs, and simply have
different storage allocation routines depending on where you want to
storage the image. To do that, you'd want to use the current swap
allocation procedure, with the ioctls you have already exported to enable
this being controlled from userspace. You'd also want to utilise bmap from
userspace for getting the sector numbers of storage. Finally, you'd want
to use bio functions to submit the I/O, and a kernel routine to handle the
completion. Then you'd need some mechanism to wait for or check for
completion of I/O on a particular page or all pages. Of course you might
decide not to do async I/O because it's too complex, but then you'd take
the performance hit you currently have, and we wouldn't have an apples
with apples comparison.
This is another place where the modular architecture in Suspend2 helps. The
I/O modules have the same basic read/write routines as the
compression/encryption support, so compression, encryption and I/O are
just strung together in a pipeline fashion. The core doesn't care whether
it's sending data directly to the I/O module, or first to a compressor or
encryptor. It just asks for the first module in the pipe, and sends each
page in the pageset to it one at a time. That module then sends data to
the next when its output buffer fills, and so on down the chain. At the
tail, the writer makes a copy of its input buffer and submits I/O on the
copy asynchronously. Simple!
e. Atomic copy/restore.
This is currently achieved in kernelspace, as it is for Suspend2. It would
seem to be extremely unlikely that this could be implemented in userspace.
Both implementations do roughly the same things, invoking the driver
model, disabling interrupts and doing the copy. Suspend2 has
DEBUG_PAGEALLOC support that adds some extra code, but the complexity
factor is minimal. (It should however be tested more frequently - IIRC I
recently got a report that it's currently broken).
f. User tuning and configuration.
uswsusp doesn't have much support for tuning and configuration at the
moment. The resume device is set from swsusp.h in the userspace program
and can be overridden using a command line option to the userspace
program. The default image size is hardwired in the userspace
swsusp.h.
Suspend2 offers far more support for tuning and configuration via a proc
interface. Suspend2 implements an additional layer on top of the base proc
routines, which might be useful elsewhere in the kernel. This layer allows
additional entries to be created at very little cost, and avoid
duplicating code for each entry. This is an area of additional complexity
that Suspend2 has at the moment, but similar additions would be helpful in
the userspace program for the same reasons.
g. Writing a full image of memory.
Not possible in uswsusp right now. If the algorithm of Suspend2 was used
(wherein LRU pages are saved separately), support would need to be added
for marking which LRU pages should be in the atomic copy (because they
belong to the freezing process), and for reading and writing the sets of
pages separately.
h. Powering down.
uswsusp currently supports using the sys_reboot restart and power off
functions. There is no support for entering the ACPI S4 state, or for
suspending-to-ram instead of powering off. Adding these would require
additional ioctls and kernelspace functions, and the capability of
configuring which powerdown method to use.
i. Status display.
The intention to implement this in userspace has been mentioned a number of
times. It is certainly possible, and is already done in Suspend2 in
userspace. It used to be done in kernel space, but was moved to userspace
because of objections by kernel developers. Moving the code to userspace
has created extra hassles for users (they now have to download extra
libraries to use the splashscreen, which were not required with the
bootsplash patch, and need to check whether an update to the userui code
is required when updating the kernel). It has also created additional
complexity in that the code for doing the userui in the kernel didn't
really go away - it was just replaced by code to communicate with
userspace and get it to do the work. On the positive side, though, it is
less code to have in the kernel, and having a font renderer in the kernel
was definitely not ideal!).
The main danger for uswsusp here would be avoiding the death of the whole
process if the userui bit hits a snag. In Suspend2, the kernel happily
continues if it can't start the userui program or talk to it. In uswsusp,
some extra measures might need to be taken to avoid this problem.
j. Summary.
At their cores, Suspend2 and uswsusp work in basically the same way. They
make an atomic copy of some/all portions of memory, saving the CPU state
in the process, and write that image to disk, doing the inverse at resume
time. The variations come in the methods by which meta-data is stored in
memory, by which the image is prepared, and in which it is stored on disk.
Suspend2 is more complex than uswsusp, but only because it has more
functionality that uswsusp. If uswsusp were to match the current Suspend2
for functionality, it would require at least a slightly greater degree of
complexity, due to the extra logic and code for implementing the
kernelspace/userspace interface. Interaction between kernespace and
userspace might be a little simpler than the current suspend2 code due to
the difference between using ioctls and using a netlink socket (but, of
course, Suspend2 code be modified to use ioctls too).
uswsusp currently moves none of the real functionality to userspace, but
rather just the controlling logic. Longer term, it might move the
compression and encryption to userspace if userspace libraries are used
for that, and eye candy might be implemented there too. In reality,
though, the bulk of the work (freezing, atomic copy, implementation of the
I/O) continues to be done in kernelspace. Doing suspend to disk in
userspace would thus be a bit of a misnomer.
It seems most likely that uswsusp would never match the current Suspend2 in
terms of functionality, or would take a very long time to get there.
Support for implementing a full image of memory will likely never happen,
and asynchronous I/O would be unlikely too. If the flexibility in how to
compress/encrypt and write the image that Suspend2 currently has were to
be implemented in uswsusp, it would require a modular architecture along
the lines of the one that has been rejected in the Modules support thread.
In short, the only way you would avoid making uswsusp at least as complex
as Suspend2 would be by failing to implement the same level of
functionality. That would of course be acceptable, but it should then be
remembered whenever you're making comparisons between the two
implementations, particularly in terms of metrics such as lines of code.
Hope this helps us progress in our discussions.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On Mon, 2006-02-06 at 14:02 +1000, Nigel Cunningham wrote:
> (they now have to download extra
> libraries to use the splashscreen, which were not required with the
> bootsplash patch, and need to check whether an update to the userui
> code
> is required when updating the kernel)
You could have avoided this problem by keeping the userspace<->kernel
interface stable.
Lee
Hi.
On Monday 06 February 2006 14:34, Lee Revell wrote:
> On Mon, 2006-02-06 at 14:02 +1000, Nigel Cunningham wrote:
> > (they now have to download extra
> > libraries to use the splashscreen, which were not required with the
> > bootsplash patch, and need to check whether an update to the userui
> > code
> > is required when updating the kernel)
>
> You could have avoided this problem by keeping the userspace<->kernel
> interface stable.
True, but sometimes you need to make changes that do modify the interface.
If the interface involves more functionality, this will happen more
frequently.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On Sat, Feb 04, 2006 at 08:57:44PM +0100, Rafael J. Wysocki wrote:
> > What about this (untested)?
>
> So you think we should chroot from the user space. Fine.
Here's what suspend2's userspace user interface currently does
before suspending.
static void enforce_lifesavers() {
struct rlimit r;
r.rlim_cur = r.rlim_max = 0;
setrlimit(RLIMIT_NOFILE, &r);
setrlimit(RLIMIT_NPROC, &r);
setrlimit(RLIMIT_CORE, &r);
}
All userspace user interfaces (text, fbsplash, usplash) share this
common code that is run before suspend itself proceeds.
Bernard.
--
Bernard Blackham <bernard at blackham dot com dot au>
On Po 06-02-06 09:44:56, Nigel Cunningham wrote:
> Hi.
>
> On Sunday 05 February 2006 05:10, Pavel Machek wrote:
> > Hi!
> >
> > > > I'm not suggesting treating them as unfreezeable in the fullest
> > > > sense. I still signal them, but don't mind if they don't respond.
> > > > This way, if they do leave that state for some reason (timeout?) at
> > > > some point, they still get frozen.
> > >
> > > Yes, that's exactly what I wanted to do in swsusp. ;-)
> >
> > It seems dangerous to me. Imagine you treated interruptible tasks like
> > that...
> >
> > What prevent task from doing
> >
> > set_state(UNINTERRUPTIBLE);
> > schedule(one hour);
> > write_to_filesystem();
> > handle_signal()?
> >
> > I.e. it may do something dangerous just before being catched by
> > refrigerator.
>
> The write_to_filesystem would be caught be bdev freezing if you had it.
But we don't... if you have bdev freezing, why do any other freezing
at all, then? It should be enough :-).
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi!
[Head straight down for j. if you hate long mails.]
> > Complexity in userspace: ungood.
> >
> > Complexity in kernel: doubleplusungood.
> >
> > It is not that hard to understand :-).
>
> Heh. you'll soon be submitting patches to move interrupt handling and
> scheduling to userspace then?
If I figure out how to do that with equivalent performance and without
excessive uglyness... yes.
[This has hidden assumption that we want to include *all* the features
suspend2 has. We could do it... but we probably do not want to.]
> a. Freezing processes, freeing memory and preparing the image.
...
> Freeing memory and preparing the image is significantly simpler for swsusp
> at the moment because it doesn't support swap files, and doesn't
I do not see why I'd have to modify freezer for supporting swap
files. It is really unrelated part. If I want to support swap files,
I'll just bmap() them from userspace, then write to blockdevice
directly, like lilo or grub does.
b. missing?
> c. Compression and encryption.
...
> libraries or using cryptoapi functions via ioctls or such like. Making
> such support optional and configurable would require further modification.
> Using userspace libraries for compression and encryption would increase
> the complexity of configuring uswsusp for a developer (extra packages to
> download/configure/install), and create greater potential for support
> issues for developers and distributions (uswusp gets blamed for any
> problems in those libraries but can't do anything to fix them!).
Yes, that is how libraries work. Any userland application has these
"problems". uswsusp is clearly better here.
> d. Storage of the image.
>
> As it currently stands, the interface between userspace and the kernel for
> uswsusp looks clean and simple. This is mainly, however, because it only
> supports writing to swap, and strictly synchronously.
...and it is going to stay that way.
> If you were going to match the functionality in suspend2, you would be
> looking at adding support for (a) asynchronous I/O, (b) for ordinary
> files, (c) for multiple swap devices (d) for swapfiles and (e) for the
> varying blocksizes of filesystems. I assume uswsusp won't currently work
> with swapfiles (as opposed to swap partitions) as it stands because I see
> a check for !S_ISBLK(resume_device) in suspend.c::main.
(a) Reading image from kernel is memory-to-memory transfer --
i.e. extremely fast. There's nothing to be gained by asynchronous
I/O. (Write to disk can still be done asynchronous, kernel has
interfaces to do that). (b) is going to be solved by bmap. Maybe I'll
need some small changes for (c) and (d); don't see why (e) applies to me.
> userspace for getting the sector numbers of storage. Finally, you'd want
> to use bio functions to submit the I/O, and a kernel routine to handle the
> completion. Then you'd need some mechanism to wait for or check for
> completion of I/O on a particular page or all pages. Of course you might
> decide not to do async I/O because it's too complex, but then you'd take
> the performance hit you currently have, and we wouldn't have an apples
> with apples comparison.
Submit bios from userspace? Eeek? We have perfectly working async io
interface for userland, and BTW going async will not give you too much
of performance advantage here...
> e. Atomic copy/restore.
>
> This is currently achieved in kernelspace, as it is for Suspend2. It would
> seem to be extremely unlikely that this could be implemented in
> userspace.
No, this stays in kernel.
> f. User tuning and configuration.
...
> Suspend2 offers far more support for tuning and configuration via a proc
> interface. Suspend2 implements an additional layer on top of the base proc
> routines, which might be useful elsewhere in the kernel. This layer allows
> additional entries to be created at very little cost, and avoid
> duplicating code for each entry. This is an area of additional complexity
> that Suspend2 has at the moment, but similar additions would be helpful in
> the userspace program for the same reasons.
uswsusp wins here -- at least it does the config stuff in userspace.
> g. Writing a full image of memory.
>
> Not possible in uswsusp right now. If the algorithm of Suspend2 was used
> (wherein LRU pages are saved separately), support would need to be added
> for marking which LRU pages should be in the atomic copy (because they
> belong to the freezing process), and for reading and writing the sets of
> pages separately.
I'm not sure if we want to save full image of memory. Saving most-used
caches only seems to work fairly well.
> h. Powering down.
>
> uswsusp currently supports using the sys_reboot restart and power off
> functions. There is no support for entering the ACPI S4 state, or for
> suspending-to-ram instead of powering off. Adding these would require
> additional ioctls and kernelspace functions, and the capability of
> configuring which powerdown method to use.
Yes, we'll need ioctls to enter S3 and S4.
Do you actually support suspend-to-ram at end of suspend2? That is one
feature I'd like to play with.
> i. Status display.
...
> is required when updating the kernel). It has also created additional
> complexity in that the code for doing the userui in the kernel didn't
> really go away - it was just replaced by code to communicate with
> userspace and get it to do the work. On the positive side, though,
As we do image writing in userspace, anyway, it does not mean
aditional interface to userspace for us.
> j. Summary.
>
> At their cores, Suspend2 and uswsusp work in basically the same
Yes, basically. They'll be similar complexity in the end, differing
very much where the complexity is.
Currently suspend2 is 14K lines of code in kernel. Not sure how much
in userspace.
Current uswsusp is 3K lines of code in kernel, 1K lines of code in
userspace.
When we are done, we'll have perhaps 2.5K lines of code in kernel
(in-kernel swap writing support goes away), and maybe 20K lines in
userspace.
That may not seem like a big difference to you, but it really is. It
keeps complexity out-of-kernel.
> It seems most likely that uswsusp would never match the current Suspend2 in
> terms of functionality, or would take a very long time to get there.
> Support for implementing a full image of memory will likely never happen,
> and asynchronous I/O would be unlikely too. If the flexibility in how to
> compress/encrypt and write the image that Suspend2 currently has were to
> be implemented in uswsusp, it would require a modular architecture along
> the lines of the one that has been rejected in the Modules support thread.
It was rejected *for kernel*. Putting it in userspace is okay.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi.
On Monday 06 February 2006 20:59, Pavel Machek wrote:
> Hi!
>
> [Head straight down for j. if you hate long mails.]
>
> > > Complexity in userspace: ungood.
> > >
> > > Complexity in kernel: doubleplusungood.
> > >
> > > It is not that hard to understand :-).
> >
> > Heh. you'll soon be submitting patches to move interrupt handling and
> > scheduling to userspace then?
>
> If I figure out how to do that with equivalent performance and without
> excessive uglyness... yes.
>
> [This has hidden assumption that we want to include *all* the features
> suspend2 has. We could do it... but we probably do not want to.]
Not hidden - I said I didn't expect you'd do most of the Suspend2 stuff,
but was trying to compare apples with apples to make the comparison fair.
> > a. Freezing processes, freeing memory and preparing the image.
>
> ...
>
> > Freeing memory and preparing the image is significantly simpler for
> > swsusp at the moment because it doesn't support swap files, and
> > doesn't
>
> I do not see why I'd have to modify freezer for supporting swap
> files. It is really unrelated part. If I want to support swap files,
> I'll just bmap() them from userspace, then write to blockdevice
> directly, like lilo or grub does.
It would be needed because they're on filesystems. Freezing the
filesystems, then trying to eat memory to the degree that the system tries
to swap would lead to a deadlock if that swap was on a frozen filesystem.
Conversely, trying to freeze the memory before freezing processes would be
unreliable because it relies on not racing against other processes trying
to work.
> b. missing?
Sorry.
> > c. Compression and encryption.
>
> ...
>
> > libraries or using cryptoapi functions via ioctls or such like. Making
> > such support optional and configurable would require further
> > modification. Using userspace libraries for compression and encryption
> > would increase the complexity of configuring uswsusp for a developer
> > (extra packages to download/configure/install), and create greater
> > potential for support issues for developers and distributions (uswusp
> > gets blamed for any problems in those libraries but can't do anything
> > to fix them!).
>
> Yes, that is how libraries work. Any userland application has these
> "problems". uswsusp is clearly better here.
How so? For Suspend2, we just use existing cryptoapi modules without any
requirement for particular libraries or such like.
> > d. Storage of the image.
> >
> > As it currently stands, the interface between userspace and the kernel
> > for uswsusp looks clean and simple. This is mainly, however, because
> > it only supports writing to swap, and strictly synchronously.
>
> ...and it is going to stay that way.
No plans for writing to anywhere else but swap?
> > If you were going to match the functionality in suspend2, you would be
> > looking at adding support for (a) asynchronous I/O, (b) for ordinary
> > files, (c) for multiple swap devices (d) for swapfiles and (e) for the
> > varying blocksizes of filesystems. I assume uswsusp won't currently
> > work with swapfiles (as opposed to swap partitions) as it stands
> > because I see a check for !S_ISBLK(resume_device) in suspend.c::main.
>
> (a) Reading image from kernel is memory-to-memory transfer --
> i.e. extremely fast. There's nothing to be gained by asynchronous
> I/O. (Write to disk can still be done asynchronous, kernel has
> interfaces to do that). (b) is going to be solved by bmap. Maybe I'll
> need some small changes for (c) and (d); don't see why (e) applies to
> me.
By I/O, I didn't mean the transfers between userspace and the kernel, but
I/O - ie writing pages to disk (or whatever).
> > userspace for getting the sector numbers of storage. Finally, you'd
> > want to use bio functions to submit the I/O, and a kernel routine to
> > handle the completion. Then you'd need some mechanism to wait for or
> > check for completion of I/O on a particular page or all pages. Of
> > course you might decide not to do async I/O because it's too complex,
> > but then you'd take the performance hit you currently have, and we
> > wouldn't have an apples with apples comparison.
>
> Submit bios from userspace? Eeek? We have perfectly working async io
Yes. But then how do you submit I/O to files on filesystems you can't
mount? You're stuck with swap partitions only forever?
> interface for userland, and BTW going async will not give you too much
> of performance advantage here...
How do you know that? Suspend2 has async I/O, and can write the image as
fast as the drive can take it. Some testing I did a while ago showed a max
throughput of 16MB/s for swsusp vs 35 (what the drive is capable of) for
Suspend2. Add LZF compression and it's 70MB/s vs 16MB/s.
> > e. Atomic copy/restore.
> >
> > This is currently achieved in kernelspace, as it is for Suspend2. It
> > would seem to be extremely unlikely that this could be implemented in
> > userspace.
>
> No, this stays in kernel.
>
> > f. User tuning and configuration.
>
> ...
>
> > Suspend2 offers far more support for tuning and configuration via a
> > proc interface. Suspend2 implements an additional layer on top of the
> > base proc routines, which might be useful elsewhere in the kernel.
> > This layer allows additional entries to be created at very little
> > cost, and avoid duplicating code for each entry. This is an area of
> > additional complexity that Suspend2 has at the moment, but similar
> > additions would be helpful in the userspace program for the same
> > reasons.
>
> uswsusp wins here -- at least it does the config stuff in userspace.
The difference is really only in how the support is exported (ioctl vs
proc).
> > g. Writing a full image of memory.
> >
> > Not possible in uswsusp right now. If the algorithm of Suspend2 was
> > used (wherein LRU pages are saved separately), support would need to
> > be added for marking which LRU pages should be in the atomic copy
> > (because they belong to the freezing process), and for reading and
> > writing the sets of pages separately.
>
> I'm not sure if we want to save full image of memory. Saving most-used
> caches only seems to work fairly well.
You're certainly doing a lot better than when you were eating everything
you could. But whether 1/2 is adequate depends on the mix of applications
and ultimately the user's requirements.
> > h. Powering down.
> >
> > uswsusp currently supports using the sys_reboot restart and power off
> > functions. There is no support for entering the ACPI S4 state, or for
> > suspending-to-ram instead of powering off. Adding these would require
> > additional ioctls and kernelspace functions, and the capability of
> > configuring which powerdown method to use.
>
> Yes, we'll need ioctls to enter S3 and S4.
Shouldn't be hard at all, either, of course.
> Do you actually support suspend-to-ram at end of suspend2? That is one
> feature I'd like to play with.
Yes (provided that S3 works on your machine normally).
> > i. Status display.
>
> ...
>
> > is required when updating the kernel). It has also created additional
> > complexity in that the code for doing the userui in the kernel didn't
> > really go away - it was just replaced by code to communicate with
> > userspace and get it to do the work. On the positive side, though,
>
> As we do image writing in userspace, anyway, it does not mean
> aditional interface to userspace for us.
But you don't. Doing image writing in userspace would involve having IDE
drivers etc in userspace. You're copying the snapshot to userspace, then
sending it straight back to the kernel one page at a time. I haven't
looked again while writing this, but I wonder if userspace even knows
exactly where the image is being stored.
> > j. Summary.
> >
> > At their cores, Suspend2 and uswsusp work in basically the same
>
> Yes, basically. They'll be similar complexity in the end, differing
> very much where the complexity is.
>
> Currently suspend2 is 14K lines of code in kernel. Not sure how much
> in userspace.
I just did wc -l on the userui svn repository *.[ch] files. I think
(Bernard's the expert) that this includes source for the text mode,
fbsplash and experimental animation uis. It looks like the text and
fbsplash onces are about 1k each and the animation one is larger, but I'm
not sure.
> Current uswsusp is 3K lines of code in kernel, 1K lines of code in
> userspace.
>
> When we are done, we'll have perhaps 2.5K lines of code in kernel
> (in-kernel swap writing support goes away), and maybe 20K lines in
> userspace.
Without adding which out of async I/O, compression, encryption, swap file
support, and ordinary file support?
> That may not seem like a big difference to you, but it really is. It
> keeps complexity out-of-kernel.
>
> > It seems most likely that uswsusp would never match the current
> > Suspend2 in terms of functionality, or would take a very long time to
> > get there. Support for implementing a full image of memory will likely
> > never happen, and asynchronous I/O would be unlikely too. If the
> > flexibility in how to compress/encrypt and write the image that
> > Suspend2 currently has were to be implemented in uswsusp, it would
> > require a modular architecture along the lines of the one that has
> > been rejected in the Modules support thread.
>
> It was rejected *for kernel*. Putting it in userspace is okay.
:)
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On Po 06-02-06 22:13:20, Nigel Cunningham wrote:
> On Monday 06 February 2006 20:59, Pavel Machek wrote:
> > I do not see why I'd have to modify freezer for supporting swap
> > files. It is really unrelated part. If I want to support swap files,
> > I'll just bmap() them from userspace, then write to blockdevice
> > directly, like lilo or grub does.
>
> It would be needed because they're on filesystems. Freezing the
> filesystems, then trying to eat memory to the degree that the system tries
> to swap would lead to a deadlock if that swap was on a frozen filesystem.
> Conversely, trying to freeze the memory before freezing processes would be
> unreliable because it relies on not racing against other processes trying
> to work.
I need to think about that one... it should be possible to allocate
space in swap file *before* freeze, and get disk address via
bmap... are you sure swapfile accesses go through filesystems? I
thought they use something bmap-like internally.
> > > d. Storage of the image.
> > >
> > > As it currently stands, the interface between userspace and the kernel
> > > for uswsusp looks clean and simple. This is mainly, however, because
> > > it only supports writing to swap, and strictly synchronously.
> >
> > ...and it is going to stay that way.
>
> No plans for writing to anywhere else but swap?
Yes, but with bmap, it is possible to do that with current
interface. Early version even supported swap partitions.
> > > userspace for getting the sector numbers of storage. Finally, you'd
> > > want to use bio functions to submit the I/O, and a kernel routine to
> > > handle the completion. Then you'd need some mechanism to wait for or
> > > check for completion of I/O on a particular page or all pages. Of
> > > course you might decide not to do async I/O because it's too complex,
> > > but then you'd take the performance hit you currently have, and we
> > > wouldn't have an apples with apples comparison.
> >
> > Submit bios from userspace? Eeek? We have perfectly working async io
>
> Yes. But then how do you submit I/O to files on filesystems you can't
> mount? You're stuck with swap partitions only forever?
read/write directly block device is perfectly possible from
userspace. Small problem is finding suspend header with the map, but
you somehow solved that already, right?
> > interface for userland, and BTW going async will not give you too much
> > of performance advantage here...
>
> How do you know that? Suspend2 has async I/O, and can write the image as
> fast as the drive can take it. Some testing I did a while ago showed a max
> throughput of 16MB/s for swsusp vs 35 (what the drive is capable of) for
> Suspend2. Add LZF compression and it's 70MB/s vs 16MB/s.
Userspace is perfectly capable of saturating I/O subsystem. No magical
"async io" is needed for that. time dd if=/dev/zero of=/dev/hda
bs=... if you don't believe me.
> > Current uswsusp is 3K lines of code in kernel, 1K lines of code in
> > userspace.
> >
> > When we are done, we'll have perhaps 2.5K lines of code in kernel
> > (in-kernel swap writing support goes away), and maybe 20K lines in
> > userspace.
>
> Without adding which out of async I/O, compression, encryption, swap file
> support, and ordinary file support?
I'll get same bandwidth as you, without need for async I/O. Async I/O
is not really a feature, suspend speed is. (There are existing
interfaces for doing AIO from userspace, anyway, but I'm pretty sure
they will not be needed
Compression, encryption, swapfile/normal file is planned, and should
not affect kernel code.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Mon, Feb 06 2006, Pavel Machek wrote:
> > > interface for userland, and BTW going async will not give you too much
> > > of performance advantage here...
> >
> > How do you know that? Suspend2 has async I/O, and can write the image as
> > fast as the drive can take it. Some testing I did a while ago showed a max
> > throughput of 16MB/s for swsusp vs 35 (what the drive is capable of) for
> > Suspend2. Add LZF compression and it's 70MB/s vs 16MB/s.
>
> Userspace is perfectly capable of saturating I/O subsystem. No magical
> "async io" is needed for that. time dd if=/dev/zero of=/dev/hda
> bs=... if you don't believe me.
But the in-kernel swsusp stuff (looking at the current linus kernel now)
does write each page to the swap in a sync manner. That definitely is
pretty slow, I would not be surprised if Nigels numbers are correct. If
you repeated without write back caching enabled, a factor 10 in slowdown
as compared to async io would not surprise me.
Why don't you split the writeout into a few seperate loops? Step 1,
submission, step 2, wait for completion, step 3, check for io errors.
You could even collapse step 2+3 if you wanted, the important bit is to
queue all the io first.
> > > Current uswsusp is 3K lines of code in kernel, 1K lines of code in
> > > userspace.
> > >
> > > When we are done, we'll have perhaps 2.5K lines of code in kernel
> > > (in-kernel swap writing support goes away), and maybe 20K lines in
> > > userspace.
> >
> > Without adding which out of async I/O, compression, encryption, swap file
> > support, and ordinary file support?
>
> I'll get same bandwidth as you, without need for async I/O. Async I/O
> is not really a feature, suspend speed is. (There are existing
> interfaces for doing AIO from userspace, anyway, but I'm pretty sure
> they will not be needed
If you keep writing single pages sync, you sure as hell wont get
anywhere near async io in speed...
--
Jens Axboe
Hi!
> > > > interface for userland, and BTW going async will not give you too much
> > > > of performance advantage here...
> > >
> > > How do you know that? Suspend2 has async I/O, and can write the image as
> > > fast as the drive can take it. Some testing I did a while ago showed a max
> > > throughput of 16MB/s for swsusp vs 35 (what the drive is capable of) for
> > > Suspend2. Add LZF compression and it's 70MB/s vs 16MB/s.
> >
> > Userspace is perfectly capable of saturating I/O subsystem. No magical
> > "async io" is needed for that. time dd if=/dev/zero of=/dev/hda
> > bs=... if you don't believe me.
>
> But the in-kernel swsusp stuff (looking at the current linus kernel now)
> does write each page to the swap in a sync manner. That definitely is
> pretty slow, I would not be surprised if Nigels numbers are correct. If
> you repeated without write back caching enabled, a factor 10 in slowdown
> as compared to async io would not surprise me.
>
> Why don't you split the writeout into a few seperate loops? Step 1,
> submission, step 2, wait for completion, step 3, check for io errors.
> You could even collapse step 2+3 if you wanted, the important bit is to
> queue all the io first.
Nigel is right for current in-kernel stuff, but even existing userland
suspend code at suspend.sf.net should solve this particular problem.
> > > > Current uswsusp is 3K lines of code in kernel, 1K lines of code in
> > > > userspace.
> > > >
> > > > When we are done, we'll have perhaps 2.5K lines of code in kernel
> > > > (in-kernel swap writing support goes away), and maybe 20K lines in
> > > > userspace.
> > >
> > > Without adding which out of async I/O, compression, encryption, swap file
> > > support, and ordinary file support?
> >
> > I'll get same bandwidth as you, without need for async I/O. Async I/O
> > is not really a feature, suspend speed is. (There are existing
> > interfaces for doing AIO from userspace, anyway, but I'm pretty sure
> > they will not be needed
>
> If you keep writing single pages sync, you sure as hell wont get
> anywhere near async io in speed...
well, we can perfectly do 128K block... just read 128K into userspace
buffer, flush it via single write to block device. That should get us
very close enough to media speed.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Mon, Feb 06 2006, Pavel Machek wrote:
> > > I'll get same bandwidth as you, without need for async I/O. Async I/O
> > > is not really a feature, suspend speed is. (There are existing
> > > interfaces for doing AIO from userspace, anyway, but I'm pretty sure
> > > they will not be needed
> >
> > If you keep writing single pages sync, you sure as hell wont get
> > anywhere near async io in speed...
>
> well, we can perfectly do 128K block... just read 128K into userspace
> buffer, flush it via single write to block device. That should get us
> very close enough to media speed.
That'll help naturally, 128k sync blocks will be very close to async
performance for most cases. Most cases here being drives with write back
caching enabled, if that is disabled async will still be a big win.
Is there any reason _not_ to just go with async io? Usually the code is
just as simple (or simpler), since the in-kernel stuff is inherently
async to begin with.
--
Jens Axboe
Hi,
On Monday 06 February 2006 14:04, Jens Axboe wrote:
> On Mon, Feb 06 2006, Pavel Machek wrote:
> > > > I'll get same bandwidth as you, without need for async I/O. Async I/O
> > > > is not really a feature, suspend speed is. (There are existing
> > > > interfaces for doing AIO from userspace, anyway, but I'm pretty sure
> > > > they will not be needed
> > >
> > > If you keep writing single pages sync, you sure as hell wont get
> > > anywhere near async io in speed...
> >
> > well, we can perfectly do 128K block... just read 128K into userspace
> > buffer, flush it via single write to block device. That should get us
> > very close enough to media speed.
>
> That'll help naturally, 128k sync blocks will be very close to async
> performance for most cases. Most cases here being drives with write back
> caching enabled, if that is disabled async will still be a big win.
>
> Is there any reason _not_ to just go with async io? Usually the code is
> just as simple (or simpler), since the in-kernel stuff is inherently
> async to begin with.
Actually the userland tools we're working on use async I/O. [There's no real
need for sync, I think.] Still we write one page at a time, for now, so the
I/O performance is not that much better than for the built-in swsusp, but it
_is_ better.
Greetings,
Rafael
On Mon, Feb 06 2006, Rafael J. Wysocki wrote:
> Hi,
>
> On Monday 06 February 2006 14:04, Jens Axboe wrote:
> > On Mon, Feb 06 2006, Pavel Machek wrote:
> > > > > I'll get same bandwidth as you, without need for async I/O. Async I/O
> > > > > is not really a feature, suspend speed is. (There are existing
> > > > > interfaces for doing AIO from userspace, anyway, but I'm pretty sure
> > > > > they will not be needed
> > > >
> > > > If you keep writing single pages sync, you sure as hell wont get
> > > > anywhere near async io in speed...
> > >
> > > well, we can perfectly do 128K block... just read 128K into userspace
> > > buffer, flush it via single write to block device. That should get us
> > > very close enough to media speed.
> >
> > That'll help naturally, 128k sync blocks will be very close to async
> > performance for most cases. Most cases here being drives with write back
> > caching enabled, if that is disabled async will still be a big win.
> >
> > Is there any reason _not_ to just go with async io? Usually the code is
> > just as simple (or simpler), since the in-kernel stuff is inherently
> > async to begin with.
>
> Actually the userland tools we're working on use async I/O. [There's
> no real need for sync, I think.] Still we write one page at a time,
> for now, so the I/O performance is not that much better than for the
> built-in swsusp, but it _is_ better.
How many pages you write out at the time doesn't matter very much - that
usually just boils down to how efficient you are wrt CPU usage,
something that suspend probably doesn't need to care a whole lot about.
What matters is how often you wait for a page. Writing 256MiB here, on a
plain SATA drive:
4k sync writes: 17.9MiB/sec
4k async writes: 29.6MiB/sec
128k sync writes: 36.0MiB/sec
128k async writes: 41.9MiB/sec
--
Jens Axboe
Hi!
> > well, we can perfectly do 128K block... just read 128K into userspace
> > buffer, flush it via single write to block device. That should get us
> > very close enough to media speed.
>
> That'll help naturally, 128k sync blocks will be very close to async
> performance for most cases. Most cases here being drives with write back
> caching enabled, if that is disabled async will still be a big win.
>
> Is there any reason _not_ to just go with async io? Usually the code is
> just as simple (or simpler), since the in-kernel stuff is inherently
> async to begin with.
Keeping it simple... when we are moving to doing writeback in
userland, anyway.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
>I'm not sure if we want to save full image of memory. Saving most-used
>caches only seems to work fairly well.
No, it sucks. My machines take forever to become usable on resume
with the current method. But dumping full image of memory will need
compression to keep that from being sluggish as well.
Mmm.. I think I need to install swsusp2 here.
Cheers
On Po 06-02-06 09:49:15, Mark Lord wrote:
> >I'm not sure if we want to save full image of memory. Saving most-used
> >caches only seems to work fairly well.
>
> No, it sucks. My machines take forever to become usable on resume
> with the current method. But dumping full image of memory will need
> compression to keep that from being sluggish as well.
Are you sure? This changed recently, be sure to set
/sys/power/image_size.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi,
On Monday 06 February 2006 00:02, Nigel Cunningham wrote:
> On Saturday 04 February 2006 23:51, Rafael J. Wysocki wrote:
> > On Saturday 04 February 2006 02:23, Pavel Machek wrote:
> > > On So 04-02-06 02:08:33, Olivier Galibert wrote:
> > > > On Sat, Feb 04, 2006 at 01:49:44AM +0100, Pavel Machek wrote:
> > > > > > Why don't you try to design the system so that the progress bar
> > > > > > can't fuck up the suspend unless they really, really want to?
> > > > > > Instead of one where a forgotten open(O_CREAT) in a corner of
> > > > > > graphics code can randomly trash the filesystem through metadata
> > > > > > corruption?
> > > > >
> > > > > Even if I only put chrome code to userspace, open() would still be
> > > > > deadly. I could do something fancy with disallowing syscalls,
> > > >
> > > > Nah, simply chroot to an empty virtual filesystem (a tmpfs with max
> > > > size=0 will do) and they can't do any fs-related fuckup anymore.
> > > > Just give them a fd through which request some specific resources
> > > > (framebuffer mmap essentially I would say) and exchange messages
> > > > with the suspend system (status, cancel, etc) and maybe log stderr
> > > > for debugging purposes and that's it. They can't do damage by
> > > > mistake anymore. They can always send signals to random pids, but
> > > > that's not called a mistake at that point.
> > > >
> > > > Even better, you can run _multiple_ processes that way, some for
> > > > compression/encryption, some for chrome, etc.
> > >
> > > No, I do not want to deal with multiple processes. Chrome code is not
> > > *as* evil as you paint it... But yes, chroot is a nice idea. Doing
> > > chroot into nowhere after freezing system will prevent most stupid
> > > mistakes. Rest of userland is frozen, so it can not do anything really
> > > wrong (at most you deadlock), if you kill someone -- well, that's only
> > > as dangerous as any other code running as root.
> >
> > I like the chroot idea too.
>
> You're making this too complicated. Just require that the userspace program
> does all it's file opening etc prior to telling kernelspace to do
> anything. Then clearly document the requirement. If someone breaks the
> rule, it is their problem, and their testing should show their
> foolishness. We have done a similar thing in the Suspend2 userspace user
> interface code, and it works fine.
Unfortunately I'd like to open at least one device file after freeze, for a
technical reason that probably does not exist in suspend2, so I need a
temporary filesystem anyway. Chrooting to it is just a cake.
[BTW, we have the list [email protected] we'd like
to be a place for discussing the userspace suspend issues. If you could
subscribe to it, we'd be able to move the discussion there.]
Greetings,
Rafael
On Mon, 2006-02-06 at 15:43 +1000, Nigel Cunningham wrote:
> Hi.
>
> On Monday 06 February 2006 14:34, Lee Revell wrote:
> > On Mon, 2006-02-06 at 14:02 +1000, Nigel Cunningham wrote:
> > > (they now have to download extra
> > > libraries to use the splashscreen, which were not required with the
> > > bootsplash patch, and need to check whether an update to the userui
> > > code
> > > is required when updating the kernel)
> >
> > You could have avoided this problem by keeping the userspace<->kernel
> > interface stable.
>
> True, but sometimes you need to make changes that do modify the interface.
> If the interface involves more functionality, this will happen more
> frequently.
Well, all I can say is, it should have been obvious that putting a
themeable UI in the kernel would not fly.
Lee
Hi.
On Tuesday 07 February 2006 04:48, Lee Revell wrote:
> On Mon, 2006-02-06 at 15:43 +1000, Nigel Cunningham wrote:
> > Hi.
> >
> > On Monday 06 February 2006 14:34, Lee Revell wrote:
> > > On Mon, 2006-02-06 at 14:02 +1000, Nigel Cunningham wrote:
> > > > (they now have to download extra
> > > > libraries to use the splashscreen, which were not required with
> > > > the bootsplash patch, and need to check whether an update to the
> > > > userui code
> > > > is required when updating the kernel)
> > >
> > > You could have avoided this problem by keeping the
> > > userspace<->kernel interface stable.
> >
> > True, but sometimes you need to make changes that do modify the
> > interface. If the interface involves more functionality, this will
> > happen more frequently.
>
> Well, all I can say is, it should have been obvious that putting a
> themeable UI in the kernel would not fly.
Agreed, but I think we have some confusion here.
I was talking about interactions between kernel space and userspace after
we started using the userspace interface. In particular, I was thinking of
the fact that the netlink message number kept changing due to changes in
the vanilla kernel. In the end, we just made it a command line option to
the userui.
My point for this conversation was different, though. If uswsusp ever does
fly, there are going to be flag days where users are going to have to
download new userspace code, perhaps new versions of libraries or new
libraries, run the compilation and reconfigure their initrds/ram-fses, all
just because they upgraded their kernel and want to continue to suspend to
disk. That is extra complexity introduced by using a userspace 'brain'
instead of having it in kernelspace.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On 02/06/06 12:56:43AM +0100, Rafael J. Wysocki wrote:
> > > > Oh. What's Pavel's solution? Fail freezing if uninterruptible threads
> > > > don't freeze?
> > >
> > > Yes.
> > >
> > > AFAICT it's to avoid situations in which we would freeze having a
> > > process in the D state that holds a semaphore or a mutex neded for
> > > suspending or resuming devices (or later on for saving the image etc.).
> > >
> > > [I didn't answer this question previously, sorry.]
> >
> > S'okay. This thread is an ocotpus :)
> >
> > Are there real life examples of this? I can't think of a single time that
> > I've heard of something like this happening. I do see rare problems with
> > storage drivers not having driver model support right, and thereby causing
> > hangs, but that's brokenness in a completely different way.
> >
> > In short, I'm wondering if (apart from the forking issue), this is a straw
> > man.
>
> It doesn't seem to be very probable to me too, but I take this argument
> as valid.
>
> Greetings,
> Rafael
CIFS was good for that, if you have a CIFS filesystem mounted and
take the network interface down (which I have my hibernate script do)
before the filesystem is umounted it'll become impossible to umount
the filesystem until the next reboot and I believe the cifsd kernel
thread will be unfreezable. It's been a while since I've done that
so it might be fixed now, but someone should verify it if it still
exists and potentially work with the CIFS people to get it fixed.
Jim.
Hi,
On Monday 06 February 2006 21:25, Nigel Cunningham wrote:
> On Tuesday 07 February 2006 04:48, Lee Revell wrote:
> > On Mon, 2006-02-06 at 15:43 +1000, Nigel Cunningham wrote:
> > > Hi.
> > >
> > > On Monday 06 February 2006 14:34, Lee Revell wrote:
> > > > On Mon, 2006-02-06 at 14:02 +1000, Nigel Cunningham wrote:
> > > > > (they now have to download extra
> > > > > libraries to use the splashscreen, which were not required with
> > > > > the bootsplash patch, and need to check whether an update to the
> > > > > userui code
> > > > > is required when updating the kernel)
> > > >
> > > > You could have avoided this problem by keeping the
> > > > userspace<->kernel interface stable.
> > >
> > > True, but sometimes you need to make changes that do modify the
> > > interface. If the interface involves more functionality, this will
> > > happen more frequently.
> >
> > Well, all I can say is, it should have been obvious that putting a
> > themeable UI in the kernel would not fly.
>
> Agreed, but I think we have some confusion here.
>
> I was talking about interactions between kernel space and userspace after
> we started using the userspace interface. In particular, I was thinking of
> the fact that the netlink message number kept changing due to changes in
> the vanilla kernel. In the end, we just made it a command line option to
> the userui.
>
> My point for this conversation was different, though. If uswsusp ever does
> fly, there are going to be flag days where users are going to have to
> download new userspace code, perhaps new versions of libraries or new
> libraries, run the compilation and reconfigure their initrds/ram-fses, all
> just because they upgraded their kernel and want to continue to suspend to
> disk. That is extra complexity introduced by using a userspace 'brain'
> instead of having it in kernelspace.
This point is valid, but I don't think the users will _have_ _to_ switch to the
userland suspend. AFAICT we are going to keep the kernel-based code
as long as necessary.
We are just going to implement features in the user space that need not be
implemented in the kernel. Of course they can be implemented in the
kernel, and you have shown that clearly, but since they need not be there,
we should at least try to implement them in the user space and see how this
works.
Frankly, I have no strong opinion on whether they _should_ be implemented
in the user space or in the kernel, but I think we won't know that until
we actually _try_.
That said, I like the idea and I'm going to work on it. I'll also appreciate
any help very much.
Greetings,
Rafael
Hi.
On Tuesday 07 February 2006 09:51, Rafael J. Wysocki wrote:
> Hi,
>
> On Monday 06 February 2006 21:25, Nigel Cunningham wrote:
> > On Tuesday 07 February 2006 04:48, Lee Revell wrote:
> > > On Mon, 2006-02-06 at 15:43 +1000, Nigel Cunningham wrote:
> > > > Hi.
> > > >
> > > > On Monday 06 February 2006 14:34, Lee Revell wrote:
> > > > > On Mon, 2006-02-06 at 14:02 +1000, Nigel Cunningham wrote:
> > > > > > (they now have to download extra
> > > > > > libraries to use the splashscreen, which were not required
> > > > > > with the bootsplash patch, and need to check whether an update
> > > > > > to the userui code
> > > > > > is required when updating the kernel)
> > > > >
> > > > > You could have avoided this problem by keeping the
> > > > > userspace<->kernel interface stable.
> > > >
> > > > True, but sometimes you need to make changes that do modify the
> > > > interface. If the interface involves more functionality, this will
> > > > happen more frequently.
> > >
> > > Well, all I can say is, it should have been obvious that putting a
> > > themeable UI in the kernel would not fly.
> >
> > Agreed, but I think we have some confusion here.
> >
> > I was talking about interactions between kernel space and userspace
> > after we started using the userspace interface. In particular, I was
> > thinking of the fact that the netlink message number kept changing due
> > to changes in the vanilla kernel. In the end, we just made it a
> > command line option to the userui.
> >
> > My point for this conversation was different, though. If uswsusp ever
> > does fly, there are going to be flag days where users are going to
> > have to download new userspace code, perhaps new versions of libraries
> > or new libraries, run the compilation and reconfigure their
> > initrds/ram-fses, all just because they upgraded their kernel and want
> > to continue to suspend to disk. That is extra complexity introduced by
> > using a userspace 'brain' instead of having it in kernelspace.
>
> This point is valid, but I don't think the users will _have_ _to_ switch
> to the userland suspend. AFAICT we are going to keep the kernel-based
> code as long as necessary.
>
> We are just going to implement features in the user space that need not
> be implemented in the kernel. Of course they can be implemented in the
> kernel, and you have shown that clearly, but since they need not be
> there, we should at least try to implement them in the user space and
> see how this works.
>
> Frankly, I have no strong opinion on whether they _should_ be
> implemented in the user space or in the kernel, but I think we won't
> know that until we actually _try_.
>
> That said, I like the idea and I'm going to work on it. I'll also
> appreciate any help very much.
Wow. I wish Pavel wrote replies like that. We'd get on a whole lot better.
Pavel, am I doing something wrong that I'm not clicking to, which is
stirring you up? I really don't want to. I want to work with you guys
instead of against you, but it seems to me like every attempt at
interaction with you degenerates into something far less than ideal.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi Jim.
On Tuesday 07 February 2006 07:07, Jim Crilly wrote:
> On 02/06/06 12:56:43AM +0100, Rafael J. Wysocki wrote:
> > > > > Oh. What's Pavel's solution? Fail freezing if uninterruptible
> > > > > threads don't freeze?
> > > >
> > > > Yes.
> > > >
> > > > AFAICT it's to avoid situations in which we would freeze having a
> > > > process in the D state that holds a semaphore or a mutex neded for
> > > > suspending or resuming devices (or later on for saving the image
> > > > etc.).
> > > >
> > > > [I didn't answer this question previously, sorry.]
> > >
> > > S'okay. This thread is an ocotpus :)
> > >
> > > Are there real life examples of this? I can't think of a single time
> > > that I've heard of something like this happening. I do see rare
> > > problems with storage drivers not having driver model support right,
> > > and thereby causing hangs, but that's brokenness in a completely
> > > different way.
> > >
> > > In short, I'm wondering if (apart from the forking issue), this is a
> > > straw man.
> >
> > It doesn't seem to be very probable to me too, but I take this
> > argument as valid.
> >
> > Greetings,
> > Rafael
>
> CIFS was good for that, if you have a CIFS filesystem mounted and
> take the network interface down (which I have my hibernate script do)
> before the filesystem is umounted it'll become impossible to umount
> the filesystem until the next reboot and I believe the cifsd kernel
> thread will be unfreezable. It's been a while since I've done that
> so it might be fixed now, but someone should verify it if it still
> exists and potentially work with the CIFS people to get it fixed.
Thanks for the pointer. I'll take a look at this.
Regards,
Nigel
> Jim.
>
> _______________________________________________
> Suspend2-devel mailing list
> [email protected]
> http://lists.suspend2.net/mailman/listinfo/suspend2-devel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Pavel Machek wrote:
> On Po 06-02-06 09:49:15, Mark Lord wrote:
>>> I'm not sure if we want to save full image of memory. Saving most-used
>>> caches only seems to work fairly well.
>> No, it sucks. My machines take forever to become usable on resume
>> with the current method. But dumping full image of memory will need
>> compression to keep that from being sluggish as well.
>
> Are you sure? This changed recently, be sure to set
> /sys/power/image_size.
No such pathname in 2.6.15 (the latest released kernel).
Cheers
On Mon, 6 Feb 2006, Mark Lord wrote:
> Pavel Machek wrote:
> > On Po 06-02-06 09:49:15, Mark Lord wrote:
> >>> I'm not sure if we want to save full image of memory. Saving most-used
> >>> caches only seems to work fairly well.
> >> No, it sucks. My machines take forever to become usable on resume
> >> with the current method. But dumping full image of memory will need
> >> compression to keep that from being sluggish as well.
> >
> > Are you sure? This changed recently, be sure to set
> > /sys/power/image_size.
>
> No such pathname in 2.6.15 (the latest released kernel).
_recently_. It's in 2.6.16-rc1 and later.
--
~Randy
Hi!
> > This point is valid, but I don't think the users will _have_ _to_ switch
> > to the userland suspend. AFAICT we are going to keep the kernel-based
> > code as long as necessary.
> >
> > We are just going to implement features in the user space that need not
> > be implemented in the kernel. Of course they can be implemented in the
> > kernel, and you have shown that clearly, but since they need not be
> > there, we should at least try to implement them in the user space and
> > see how this works.
> >
> > Frankly, I have no strong opinion on whether they _should_ be
> > implemented in the user space or in the kernel, but I think we won't
> > know that until we actually _try_.
> >
> > That said, I like the idea and I'm going to work on it. I'll also
> > appreciate any help very much.
>
> Wow. I wish Pavel wrote replies like that. We'd get on a whole lot better.
>
> Pavel, am I doing something wrong that I'm not clicking to, which is
> stirring you up? I really don't want to. I want to work with you guys
> instead of against you, but it seems to me like every attempt at
> interaction with you degenerates into something far less than ideal.
Nothing I could name... I guess I'll just let you cooperate with
Rafael, he can translate ;-).
[Well, perhaps there's one thing. Have you seen Al Viro's mails? He
tends to use quite a strong language. I guess asking you to talk like
him is too much to ask (but it would probably help ;-), but notice
that my and his native languages have quite a lot in common. Perhaps
I'm doing poor job translating into English at higher level...]
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Quoting "Rafael J. Wysocki" <[email protected]>:
> This point is valid, but I don't think the users will _have_ _to_
> switch to the
> userland suspend. AFAICT we are going to keep the kernel-based code
> as long as necessary.
Yep, that's what I thought too. Read on...
> We are just going to implement features in the user space that need not be
> implemented in the kernel. Of course they can be implemented in the
> kernel, and you have shown that clearly, but since they need not be there,
> we should at least try to implement them in the user space and see how this
> works.
Well, given that the kernel suspend is going to be kept for a while,
wouldn't it be better if it was feature full? How would the users be at
a disadvantage if they had better kernel based suspend for a while,
followed by u-beaut-cooks-cleans-and-washes uswsusp? That's the part I
don't get...
So, to be direct, let me ask:
Why is it so important to keep an inferior implementation of kernel
based suspend, when a better one and field tested, exists?
--
Bojan
On 02/07/06 12:51:40AM +0100, Rafael J. Wysocki wrote:
> Hi,
>
> This point is valid, but I don't think the users will _have_ _to_ switch to the
> userland suspend. AFAICT we are going to keep the kernel-based code
> as long as necessary.
>
> We are just going to implement features in the user space that need not be
> implemented in the kernel. Of course they can be implemented in the
> kernel, and you have shown that clearly, but since they need not be there,
> we should at least try to implement them in the user space and see how this
> works.
>
> Frankly, I have no strong opinion on whether they _should_ be implemented
> in the user space or in the kernel, but I think we won't know that until
> we actually _try_.
>
Some of the stuff belongs in userspace without a doubt, like the UI. But
why was the cryptoapi stuff added to the kernel if everytime someone goes
to use it people yell "That's too much complexity, do it in userspace!"?
> That said, I like the idea and I'm going to work on it. I'll also appreciate
> any help very much.
>
> Greetings,
> Rafael
Jim.
Are you Max Dubois, second incarnation or what?
> Well, given that the kernel suspend is going to be kept for a while,
> wouldn't it be better if it was feature full? How would the users be at
~~~~~~~~~~~~~~~~~~~~~~~~~
> a disadvantage if they had better kernel based suspend for a while,
~~~~~~~~~~~~~~~~
> followed by u-beaut-cooks-cleans-and-washes uswsusp? That's the part I
> don't get...
*Users* would not be at disadvantage, but, surprise, there's one thing
more important than users. Thats developers, and I can guarantee you
that merging 14K lines of code just to delete them half a year later
would drive them crazy.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Po 06-02-06 19:37:13, Jim Crilly wrote:
> On 02/07/06 12:51:40AM +0100, Rafael J. Wysocki wrote:
> > Hi,
> >
> > This point is valid, but I don't think the users will _have_ _to_ switch to the
> > userland suspend. AFAICT we are going to keep the kernel-based code
> > as long as necessary.
> >
> > We are just going to implement features in the user space that need not be
> > implemented in the kernel. Of course they can be implemented in the
> > kernel, and you have shown that clearly, but since they need not be there,
> > we should at least try to implement them in the user space and see how this
> > works.
> >
> > Frankly, I have no strong opinion on whether they _should_ be implemented
> > in the user space or in the kernel, but I think we won't know that until
> > we actually _try_.
> >
>
> Some of the stuff belongs in userspace without a doubt, like the UI. But
> why was the cryptoapi stuff added to the kernel if everytime someone goes
> to use it people yell "That's too much complexity, do it in userspace!"?
For stuff that can't be reasonably done in userspace, like encrypted
loop. And notice that cryptoapi does *not* yet contain LZW.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi.
On Tuesday 07 February 2006 10:29, Pavel Machek wrote:
> Hi!
>
> > > This point is valid, but I don't think the users will _have_ _to_
> > > switch to the userland suspend. AFAICT we are going to keep the
> > > kernel-based code as long as necessary.
> > >
> > > We are just going to implement features in the user space that need
> > > not be implemented in the kernel. Of course they can be implemented
> > > in the kernel, and you have shown that clearly, but since they need
> > > not be there, we should at least try to implement them in the user
> > > space and see how this works.
> > >
> > > Frankly, I have no strong opinion on whether they _should_ be
> > > implemented in the user space or in the kernel, but I think we won't
> > > know that until we actually _try_.
> > >
> > > That said, I like the idea and I'm going to work on it. I'll also
> > > appreciate any help very much.
> >
> > Wow. I wish Pavel wrote replies like that. We'd get on a whole lot
> > better.
> >
> > Pavel, am I doing something wrong that I'm not clicking to, which is
> > stirring you up? I really don't want to. I want to work with you guys
> > instead of against you, but it seems to me like every attempt at
> > interaction with you degenerates into something far less than ideal.
>
> Nothing I could name... I guess I'll just let you cooperate with
> Rafael, he can translate ;-).
:>
> [Well, perhaps there's one thing. Have you seen Al Viro's mails? He
> tends to use quite a strong language. I guess asking you to talk like
> him is too much to ask (but it would probably help ;-), but notice
Heh. Maybe I should look at some, after reading that!
Maybe I can also encourage you to try not to sound so confontational?
Perhaps we can meet half way.
> that my and his native languages have quite a lot in common. Perhaps
> I'm doing poor job translating into English at higher level...]
Well, if we know it's just a communication and not a clash of
personalities, that alone should help.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On 02/07/06 01:46:11AM +0100, Pavel Machek wrote:
> On Po 06-02-06 19:37:13, Jim Crilly wrote:
> > On 02/07/06 12:51:40AM +0100, Rafael J. Wysocki wrote:
> > > Hi,
> > >
> > > This point is valid, but I don't think the users will _have_ _to_ switch to the
> > > userland suspend. AFAICT we are going to keep the kernel-based code
> > > as long as necessary.
> > >
> > > We are just going to implement features in the user space that need not be
> > > implemented in the kernel. Of course they can be implemented in the
> > > kernel, and you have shown that clearly, but since they need not be there,
> > > we should at least try to implement them in the user space and see how this
> > > works.
> > >
> > > Frankly, I have no strong opinion on whether they _should_ be implemented
> > > in the user space or in the kernel, but I think we won't know that until
> > > we actually _try_.
> > >
> >
> > Some of the stuff belongs in userspace without a doubt, like the UI. But
> > why was the cryptoapi stuff added to the kernel if everytime someone goes
> > to use it people yell "That's too much complexity, do it in userspace!"?
>
> For stuff that can't be reasonably done in userspace, like encrypted
> loop. And notice that cryptoapi does *not* yet contain LZW.
> Pavel
>
I guess reasonable is a subjective term. For instance, I've seen quite a
few people vehemently against adding new ioctls to the kernel and yet
you'll be adding quite a few for /dev/snapshot. I'm just of the same mind
as Nigel in that it makes the most sense to me that the majority of the
suspend/hibernation process to be in the kernel.
And I realize lzf compression isn't in the main kernel yet, but cryptoapi
was designed to be modular so that new things can be added later if
necessary and deflate is already there, so it's not like there's no
compression algorithms included yet.
Jim.
Hi Pavel.
On Tuesday 07 February 2006 10:44, Pavel Machek wrote:
> Are you Max Dubois, second incarnation or what?
>
> > Well, given that the kernel suspend is going to be kept for a while,
> > wouldn't it be better if it was feature full? How would the users be
> > at
>
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>
> > a disadvantage if they had better kernel based suspend for a while,
>
> ~~~~~~~~~~~~~~~~
>
> > followed by u-beaut-cooks-cleans-and-washes uswsusp? That's the part I
> > don't get...
>
> *Users* would not be at disadvantage, but, surprise, there's one thing
> more important than users. Thats developers, and I can guarantee you
> that merging 14K lines of code just to delete them half a year later
> would drive them crazy.
It would more be an ever-changing interface that would drive them crazy. So
why don't we come up with an agreed method of starting a suspend and
starting a resume that they can use, without worrying about whether
they're getting swsusp, uswsusp or Suspend2? /sys/power/state seems the
obvious choice for this. An additional /sys entry could perhaps be used to
modify which implementation is used when you echo disk > /sys/power/state
- something like
# cat /sys/power/disk_method
swsusp uswsusp suspend2
# echo uswsusp > /sys/power/disk_method
# echo > /sys/power/state
Is there a big problem with that, which I've missed?
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On Mon, 2006-02-06 at 19:59 -0500, Jim Crilly wrote:
> I guess reasonable is a subjective term. For instance, I've seen quite
> a few people vehemently against adding new ioctls to the kernel and
> yet you'll be adding quite a few for /dev/snapshot. I'm just of the
> same mind as Nigel in that it makes the most sense to me that the
> majority of the suspend/hibernation process to be in the kernel.
No one is saying that ANY new ioctls are bad, just that the KISS
principle of engineering dictates that it's bad design to use ioctls
where a simple read/write to a sysfs file will do.
Lee
Quoting Pavel Machek <[email protected]>:
> Are you Max Dubois, second incarnation or what?
Sorry mate, no. Can't do music for shit.
> *Users* would not be at disadvantage, but, surprise, there's one thing
> more important than users. Thats developers, and I can guarantee you
> that merging 14K lines of code just to delete them half a year later
> would drive them crazy.
Yeah, you meant "a developer", I'm sure :-)
What makes you think that all 14k lines would get removed? Or is it
that you don't want users (oh, here is that dirty word again :-)
getting used to something that works better, which may mean that all
14k lines stay?
--
Bojan
On 02/06/06 08:19:02PM -0500, Lee Revell wrote:
> On Mon, 2006-02-06 at 19:59 -0500, Jim Crilly wrote:
> > I guess reasonable is a subjective term. For instance, I've seen quite
> > a few people vehemently against adding new ioctls to the kernel and
> > yet you'll be adding quite a few for /dev/snapshot. I'm just of the
> > same mind as Nigel in that it makes the most sense to me that the
> > majority of the suspend/hibernation process to be in the kernel.
>
> No one is saying that ANY new ioctls are bad, just that the KISS
> principle of engineering dictates that it's bad design to use ioctls
> where a simple read/write to a sysfs file will do.
>
I understand that, but shouldn't the KISS principle also be applied to
the user interface of a feature? As it stands it looks like Suspend2
is going to be a lot simpler for users to configure and get right than
uswsusp. As long as you have Suspend2 enabled in the kernel it 'just
works', even if you don't have the userland UI it'll still suspend and
resume just without the progress bars. There is still some room for error
with things like forgetting to enable the swap writer and then attempting
to suspend to a swap device or making lzf a module and forgetting to
load it before resuming from a compressed image, but those are no worse
than any other kernel option.
With uswsusp it'll be more flexible in that you'll be able to use any
userland process or library to transform the image before storing it, but
the suspend and resume processes are going to be a lot more complicated.
For instance, how are you going to tell the kernel that you need the
uswsusp UI binary, /bin/gzip and /usr/bin/gpg to run after the rest of
userland has been frozen?
Jim.
Hi Jim.
On Tuesday 07 February 2006 13:01, Jim Crilly wrote:
> On 02/06/06 08:19:02PM -0500, Lee Revell wrote:
> > On Mon, 2006-02-06 at 19:59 -0500, Jim Crilly wrote:
> > > I guess reasonable is a subjective term. For instance, I've seen
> > > quite a few people vehemently against adding new ioctls to the
> > > kernel and yet you'll be adding quite a few for /dev/snapshot. I'm
> > > just of the same mind as Nigel in that it makes the most sense to me
> > > that the majority of the suspend/hibernation process to be in the
> > > kernel.
> >
> > No one is saying that ANY new ioctls are bad, just that the KISS
> > principle of engineering dictates that it's bad design to use ioctls
> > where a simple read/write to a sysfs file will do.
>
> I understand that, but shouldn't the KISS principle also be applied to
> the user interface of a feature? As it stands it looks like Suspend2
> is going to be a lot simpler for users to configure and get right than
> uswsusp. As long as you have Suspend2 enabled in the kernel it 'just
> works', even if you don't have the userland UI it'll still suspend and
> resume just without the progress bars. There is still some room for
> error with things like forgetting to enable the swap writer and then
> attempting to suspend to a swap device or making lzf a module and
> forgetting to load it before resuming from a compressed image, but those
> are no worse than any other kernel option.
>
> With uswsusp it'll be more flexible in that you'll be able to use any
> userland process or library to transform the image before storing it,
> but the suspend and resume processes are going to be a lot more
> complicated. For instance, how are you going to tell the kernel that you
> need the uswsusp UI binary, /bin/gzip and /usr/bin/gpg to run after the
> rest of userland has been frozen?
As I understand it, with uswsusp, all the functionality will be compiled
into one monolithic binary, which you'll also need to put in your initrd
or initramfs.
Hope that helps.
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On Mon, 2006-02-06 at 22:01 -0500, Jim Crilly wrote:
> On 02/06/06 08:19:02PM -0500, Lee Revell wrote:
> > On Mon, 2006-02-06 at 19:59 -0500, Jim Crilly wrote:
> > > I guess reasonable is a subjective term. For instance, I've seen quite
> > > a few people vehemently against adding new ioctls to the kernel and
> > > yet you'll be adding quite a few for /dev/snapshot. I'm just of the
> > > same mind as Nigel in that it makes the most sense to me that the
> > > majority of the suspend/hibernation process to be in the kernel.
> >
> > No one is saying that ANY new ioctls are bad, just that the KISS
> > principle of engineering dictates that it's bad design to use ioctls
> > where a simple read/write to a sysfs file will do.
> >
>
> I understand that, but shouldn't the KISS principle also be applied to
> the user interface of a feature?
Personally I agree with you on suspend2, I think this is something that
needed to Just Work yesterday, and every day it doesn't work we are
losing users... but who am I to talk, I'm not the one who will have to
maintain it.
Lee
On Mon, 2006-02-06 at 22:01 -0500, Jim Crilly wrote:
> With uswsusp it'll be more flexible in that you'll be able to use any
> userland process or library to transform the image before storing it, but
> the suspend and resume processes are going to be a lot more complicated.
> For instance, how are you going to tell the kernel that you need the
> uswsusp UI binary, /bin/gzip and /usr/bin/gpg to run after the rest of
> userland has been frozen?
Unless someone at least gives a rough estimate of 1) what % of users
can't suspend their laptops now and 2) of these, what % are helped by
suspend2, this thread is just handwaving...
Lee
Hi.
On Tuesday 07 February 2006 13:13, Lee Revell wrote:
> On Mon, 2006-02-06 at 22:01 -0500, Jim Crilly wrote:
> > On 02/06/06 08:19:02PM -0500, Lee Revell wrote:
> > > On Mon, 2006-02-06 at 19:59 -0500, Jim Crilly wrote:
> > > > I guess reasonable is a subjective term. For instance, I've seen
> > > > quite a few people vehemently against adding new ioctls to the
> > > > kernel and yet you'll be adding quite a few for /dev/snapshot. I'm
> > > > just of the same mind as Nigel in that it makes the most sense to
> > > > me that the majority of the suspend/hibernation process to be in
> > > > the kernel.
> > >
> > > No one is saying that ANY new ioctls are bad, just that the KISS
> > > principle of engineering dictates that it's bad design to use ioctls
> > > where a simple read/write to a sysfs file will do.
> >
> > I understand that, but shouldn't the KISS principle also be applied to
> > the user interface of a feature?
>
> Personally I agree with you on suspend2, I think this is something that
> needed to Just Work yesterday, and every day it doesn't work we are
> losing users... but who am I to talk, I'm not the one who will have to
> maintain it.
Well, I will have to maintain it, and I'm perfectly willing to. I only
started to work on it in the first place because I wanted to use it, so I
have a vested interest in keeping it working. So... even if we end up
pulling it out in place of a userspace solution, I really like the idea of
putting it in at least until uswsusp is up to speed (provided it didn't
given Andrew and/or Linus a hernia in the process).
To avoid the backwards compatability issues, we can plan ahead now,
defining something like I suggested in another email earlier in the day.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On Tuesday 07 February 2006 13:17, Lee Revell wrote:
> On Mon, 2006-02-06 at 22:01 -0500, Jim Crilly wrote:
> > With uswsusp it'll be more flexible in that you'll be able to use any
> > userland process or library to transform the image before storing it,
> > but the suspend and resume processes are going to be a lot more
> > complicated. For instance, how are you going to tell the kernel that
> > you need the uswsusp UI binary, /bin/gzip and /usr/bin/gpg to run
> > after the rest of userland has been frozen?
>
> Unless someone at least gives a rough estimate of 1) what % of users
> can't suspend their laptops now and 2) of these, what % are helped by
> suspend2, this thread is just handwaving...
Percentages would be pure guesswork, but I do have _some_ numbers.
For (1), I have no idea. Furthermore, I would think that if a user can
suspend with Suspend2, they should be able to suspend with swsusp. There
were 2 driver related patches I had that swsusp doesn't, with I sent to
Andrew and to John Stultz this morning for consideration. The one sent to
Andrew might make some people be able to suspend with Suspend2 who
couldn't with swsusp, but I couldn't see how the timer related one I sent
to John could make a difference (so I asked for his evaluation). Given
that the right thing happens with them, I guess merging Suspend2 should
make virtually zero difference to whatever the answer might be to #1.
Now to #2.I haven't seen download statistics for Suspend2 since last May.
At that time, we had a release that was current for about 3 months. During
that time, there were 12,000 downloads of the version (2.1.8 IIRC). Let's
say that half of them actually applied the software and used it. Does 6000
people make it worth it? Of course, having said that, I don't know how
many people would be more likely to use it if it was in mainline and they
didn't have to patch their kernels, but I'd suspect it would be at least
that number again.
Hope that helps.
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Quoting Nigel Cunningham <[email protected]>:
> Of course, having said that, I don't know how
> many people would be more likely to use it if it was in mainline and they
> didn't have to patch their kernels, but I'd suspect it would be at least
> that number again.
Well, there are far more people that use what distrubutions provide
than anything else. And distributions tend to like applying some
patches to the vanilla kernel, but if at all possible, not to be too
far away from mainline. Which is a good policy, of course, as it
reduces the amount of work for them and makes them submit improvements
upstream.
So, when distributors are able to get their hands on something that
Just Works in the mainline, they will make sure things are nicely
integrated, variety of configs are supported (like suspending to swap
partitions, swap files or regular files), that the whole thing looks
pretty and performs well. All of this can be done with Suspend2 today.
So, it isn't just about the basics any more (i.e. who can suspend and
who cannot). Majority of users prefer things that work better, are
faster and look prettier.
--
Bojan
Hi!
> > *Users* would not be at disadvantage, but, surprise, there's one thing
> > more important than users. Thats developers, and I can guarantee you
> > that merging 14K lines of code just to delete them half a year later
> > would drive them crazy.
>
> It would more be an ever-changing interface that would drive them crazy. So
> why don't we come up with an agreed method of starting a suspend and
> starting a resume that they can use, without worrying about whether
> they're getting swsusp, uswsusp or Suspend2? /sys/power/state seems the
> obvious choice for this. An additional /sys entry could perhaps be used to
> modify which implementation is used when you echo disk > /sys/power/state
> - something like
>
> # cat /sys/power/disk_method
> swsusp uswsusp suspend2
> # echo uswsusp > /sys/power/disk_method
> # echo > /sys/power/state
>
> Is there a big problem with that, which I've missed?
Well, for _users_ method seems to be clicking "suspend" in KDE. For
more experienced users it is powersave -U. And you are already
distributing script to do suspend... Just hook suspend2 to the same
gui stuff distributions already use.
Besides what you described can't work for uswsusp.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Po 06-02-06 22:17:04, Lee Revell wrote:
> On Mon, 2006-02-06 at 22:01 -0500, Jim Crilly wrote:
> > With uswsusp it'll be more flexible in that you'll be able to use any
> > userland process or library to transform the image before storing it, but
> > the suspend and resume processes are going to be a lot more complicated.
> > For instance, how are you going to tell the kernel that you need the
> > uswsusp UI binary, /bin/gzip and /usr/bin/gpg to run after the rest of
> > userland has been frozen?
>
> Unless someone at least gives a rough estimate of 1) what % of users
> can't suspend their laptops now and 2) of these, what % are helped by
> suspend2, this thread is just handwaving...
and 3) for what % of users, suspend2 will actually break it (bugs
happen).
Anyway it seems to be something like 1) 90% 2) 1% 3) .5%
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Po 06-02-06 22:13:36, Lee Revell wrote:
> On Mon, 2006-02-06 at 22:01 -0500, Jim Crilly wrote:
> > On 02/06/06 08:19:02PM -0500, Lee Revell wrote:
> > > On Mon, 2006-02-06 at 19:59 -0500, Jim Crilly wrote:
> > > > I guess reasonable is a subjective term. For instance, I've seen quite
> > > > a few people vehemently against adding new ioctls to the kernel and
> > > > yet you'll be adding quite a few for /dev/snapshot. I'm just of the
> > > > same mind as Nigel in that it makes the most sense to me that the
> > > > majority of the suspend/hibernation process to be in the kernel.
> > >
> > > No one is saying that ANY new ioctls are bad, just that the KISS
> > > principle of engineering dictates that it's bad design to use ioctls
> > > where a simple read/write to a sysfs file will do.
> > >
> >
> > I understand that, but shouldn't the KISS principle also be applied to
> > the user interface of a feature?
>
> Personally I agree with you on suspend2, I think this is something that
> needed to Just Work yesterday, and every day it doesn't work we are
> losing users... but who am I to talk, I'm not the one who will have to
> maintain it.
It does just work in mainline now. If it does not please open bug
account at bugzilla.kernel.org.
If mainline swsusp is too slow for you, install uswsusp. If it is
still too slow for you, mail me a patch adding LZW to userland code
(should be easy).
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Tue, Feb 07, 2006 at 01:32:46PM +1000, Nigel Cunningham wrote:
> Now to #2.I haven't seen download statistics for Suspend2 since last May.
> At that time, we had a release that was current for about 3 months. During
> that time, there were 12,000 downloads of the version (2.1.8 IIRC). Let's
> say that half of them actually applied the software and used it. Does 6000
> people make it worth it? Of course, having said that, I don't know how
> many people would be more likely to use it if it was in mainline and they
> didn't have to patch their kernels, but I'd suspect it would be at least
> that number again.
And those downloads doesn't include the users of distributions, where
suspend2 is already well integrated. In Gentoo, for instance, we
mirror the suspend2 patches on our own mirror system (We didn't do
this last May, though).
Regards,
Brix
--
Henrik Brix Andersen <[email protected]>
Gentoo Metadistribution | Mobile computing herd
Hi,
On Tuesday 07 February 2006 02:05, Nigel Cunningham wrote:
> On Tuesday 07 February 2006 10:44, Pavel Machek wrote:
> > Are you Max Dubois, second incarnation or what?
> >
> > > Well, given that the kernel suspend is going to be kept for a while,
> > > wouldn't it be better if it was feature full? How would the users be
> > > at
> >
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~
> >
> > > a disadvantage if they had better kernel based suspend for a while,
> >
> > ~~~~~~~~~~~~~~~~
> >
> > > followed by u-beaut-cooks-cleans-and-washes uswsusp? That's the part I
> > > don't get...
> >
> > *Users* would not be at disadvantage, but, surprise, there's one thing
> > more important than users. Thats developers, and I can guarantee you
> > that merging 14K lines of code just to delete them half a year later
> > would drive them crazy.
>
> It would more be an ever-changing interface that would drive them crazy. So
> why don't we come up with an agreed method of starting a suspend and
> starting a resume that they can use, without worrying about whether
> they're getting swsusp, uswsusp or Suspend2? /sys/power/state seems the
> obvious choice for this. An additional /sys entry could perhaps be used to
> modify which implementation is used when you echo disk > /sys/power/state
> - something like
>
> # cat /sys/power/disk_method
> swsusp uswsusp suspend2
> # echo uswsusp > /sys/power/disk_method
> # echo > /sys/power/state
>
> Is there a big problem with that, which I've missed?
Userland suspend is driven by the suspending application which only calls
the kernel to do things it cannot do itself, like freezing (the other)
processes, snapshotting the system etc. We use the /dev/snapshot
device and the ioctl()s in there, so no sysfs files are needed for that.
It's independent and can coexist with the existing sysfs interface
just fine.
Greetings,
Rafael
Hi,
On Tuesday 07 February 2006 01:16, Nigel Cunningham wrote:
> On Tuesday 07 February 2006 07:07, Jim Crilly wrote:
> > On 02/06/06 12:56:43AM +0100, Rafael J. Wysocki wrote:
> > > > > > Oh. What's Pavel's solution? Fail freezing if uninterruptible
> > > > > > threads don't freeze?
> > > > >
> > > > > Yes.
> > > > >
> > > > > AFAICT it's to avoid situations in which we would freeze having a
> > > > > process in the D state that holds a semaphore or a mutex neded for
> > > > > suspending or resuming devices (or later on for saving the image
> > > > > etc.).
> > > > >
> > > > > [I didn't answer this question previously, sorry.]
> > > >
> > > > S'okay. This thread is an ocotpus :)
> > > >
> > > > Are there real life examples of this? I can't think of a single time
> > > > that I've heard of something like this happening. I do see rare
> > > > problems with storage drivers not having driver model support right,
> > > > and thereby causing hangs, but that's brokenness in a completely
> > > > different way.
> > > >
> > > > In short, I'm wondering if (apart from the forking issue), this is a
> > > > straw man.
> > >
> > > It doesn't seem to be very probable to me too, but I take this
> > > argument as valid.
> > >
> > > Greetings,
> > > Rafael
> >
> > CIFS was good for that, if you have a CIFS filesystem mounted and
> > take the network interface down (which I have my hibernate script do)
> > before the filesystem is umounted it'll become impossible to umount
> > the filesystem until the next reboot and I believe the cifsd kernel
> > thread will be unfreezable. It's been a while since I've done that
> > so it might be fixed now, but someone should verify it if it still
> > exists and potentially work with the CIFS people to get it fixed.
>
> Thanks for the pointer. I'll take a look at this.
Yes, that's interesting. If we have an actual test case, it'll help us a lot.
Greetings,
Rafael
On Tue, 2006-02-07 at 10:33 +0100, Pavel Machek wrote:
> > Unless someone at least gives a rough estimate of 1) what % of users
> > can't suspend their laptops now and 2) of these, what % are helped
> by
> > suspend2, this thread is just handwaving...
>
> and 3) for what % of users, suspend2 will actually break it (bugs
> happen).
>
> Anyway it seems to be something like 1) 90% 2) 1% 3) .5%
Presumably you mean 90% *can* suspend with mainline?
Lee
On ?t 07-02-06 10:47:48, Lee Revell wrote:
> On Tue, 2006-02-07 at 10:33 +0100, Pavel Machek wrote:
> > > Unless someone at least gives a rough estimate of 1) what % of users
> > > can't suspend their laptops now and 2) of these, what % are helped
> > by
> > > suspend2, this thread is just handwaving...
> >
> > and 3) for what % of users, suspend2 will actually break it (bugs
> > happen).
> >
> > Anyway it seems to be something like 1) 90% 2) 1% 3) .5%
>
> Presumably you mean 90% *can* suspend with mainline?
Yes, sorry.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi.
On Tuesday 07 February 2006 19:33, Pavel Machek wrote:
> On Po 06-02-06 22:17:04, Lee Revell wrote:
> > On Mon, 2006-02-06 at 22:01 -0500, Jim Crilly wrote:
> > > With uswsusp it'll be more flexible in that you'll be able to use any
> > > userland process or library to transform the image before storing it,
but
> > > the suspend and resume processes are going to be a lot more
complicated.
> > > For instance, how are you going to tell the kernel that you need the
> > > uswsusp UI binary, /bin/gzip and /usr/bin/gpg to run after the rest
of
> > > userland has been frozen?
> >
> > Unless someone at least gives a rough estimate of 1) what % of users
> > can't suspend their laptops now and 2) of these, what % are helped by
> > suspend2, this thread is just handwaving...
>
> and 3) for what % of users, suspend2 will actually break it (bugs
> happen).
Yep, I'm fallible too :) Which is why we have a mailing list and
bugzilla :)
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Wednesday 08 February 2006 01:09, Rafael J. Wysocki wrote:
> Hi,
>
> On Tuesday 07 February 2006 02:05, Nigel Cunningham wrote:
> > On Tuesday 07 February 2006 10:44, Pavel Machek wrote:
> > > Are you Max Dubois, second incarnation or what?
> > >
> > > > Well, given that the kernel suspend is going to be kept for a
while,
> > > > wouldn't it be better if it was feature full? How would the users
be
> > > > at
> > >
> > >
> > > ~~~~~~~~~~~~~~~~~~~~~~~~~
> > >
> > > > a disadvantage if they had better kernel based suspend for a while,
> > >
> > > ~~~~~~~~~~~~~~~~
> > >
> > > > followed by u-beaut-cooks-cleans-and-washes uswsusp? That's the
part I
> > > > don't get...
> > >
> > > *Users* would not be at disadvantage, but, surprise, there's one
thing
> > > more important than users. Thats developers, and I can guarantee you
> > > that merging 14K lines of code just to delete them half a year later
> > > would drive them crazy.
> >
> > It would more be an ever-changing interface that would drive them
crazy. So
> > why don't we come up with an agreed method of starting a suspend and
> > starting a resume that they can use, without worrying about whether
> > they're getting swsusp, uswsusp or Suspend2? /sys/power/state seems the
> > obvious choice for this. An additional /sys entry could perhaps be used
to
> > modify which implementation is used when you echo disk
> /sys/power/state
> > - something like
> >
> > # cat /sys/power/disk_method
> > swsusp uswsusp suspend2
> > # echo uswsusp > /sys/power/disk_method
> > # echo > /sys/power/state
> >
> > Is there a big problem with that, which I've missed?
>
> Userland suspend is driven by the suspending application which only calls
> the kernel to do things it cannot do itself, like freezing (the other)
> processes, snapshotting the system etc. We use the /dev/snapshot
> device and the ioctl()s in there, so no sysfs files are needed for that.
> It's independent and can coexist with the existing sysfs interface
> just fine.
Yes, but how are you going to get it started from (say) klaptop, which only
knows "echo disk > /sys/power/state" as the way of starting a suspend? I'm
suggesting that we create a means whereby the issue of how to start a
cycle could be separated from what implementation is used to do the work.
That is, a simple extension at the start of the disk specific code that
starts swsusp, uswsusp or suspend2 depending upon what you want. Maybe I
should just prepare a patch.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Tuesday 07 February 2006 19:37, Pavel Machek wrote:
> On Po 06-02-06 22:13:36, Lee Revell wrote:
> > On Mon, 2006-02-06 at 22:01 -0500, Jim Crilly wrote:
> > > On 02/06/06 08:19:02PM -0500, Lee Revell wrote:
> > > > On Mon, 2006-02-06 at 19:59 -0500, Jim Crilly wrote:
> > > > > I guess reasonable is a subjective term. For instance, I've seen
quite
> > > > > a few people vehemently against adding new ioctls to the kernel
and
> > > > > yet you'll be adding quite a few for /dev/snapshot. I'm just of
the
> > > > > same mind as Nigel in that it makes the most sense to me that the
> > > > > majority of the suspend/hibernation process to be in the kernel.
> > > >
> > > > No one is saying that ANY new ioctls are bad, just that the KISS
> > > > principle of engineering dictates that it's bad design to use
ioctls
> > > > where a simple read/write to a sysfs file will do.
> > > >
> > >
> > > I understand that, but shouldn't the KISS principle also be applied
to
> > > the user interface of a feature?
> >
> > Personally I agree with you on suspend2, I think this is something that
> > needed to Just Work yesterday, and every day it doesn't work we are
> > losing users... but who am I to talk, I'm not the one who will have to
> > maintain it.
>
> It does just work in mainline now. If it does not please open bug
> account at bugzilla.kernel.org.
>
> If mainline swsusp is too slow for you, install uswsusp. If it is
> still too slow for you, mail me a patch adding LZW to userland code
> (should be easy).
<horrified rebuke>
Pavel!
Responses like this are precisely why you're not the most popular kernel
maintainer. Telling people to use beta (alpha?) code or fix it themselves
(and then have their patches rejected by you) is no way to maintain a part
of the kernel. Stop being a liability instead of an asset!
</horrified rebuke>
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Tuesday 07 February 2006 19:33, Pavel Machek wrote:
> On Po 06-02-06 22:17:04, Lee Revell wrote:
> > On Mon, 2006-02-06 at 22:01 -0500, Jim Crilly wrote:
> > > With uswsusp it'll be more flexible in that you'll be able to use any
> > > userland process or library to transform the image before storing it, but
> > > the suspend and resume processes are going to be a lot more complicated.
> > > For instance, how are you going to tell the kernel that you need the
> > > uswsusp UI binary, /bin/gzip and /usr/bin/gpg to run after the rest of
> > > userland has been frozen?
> >
> > Unless someone at least gives a rough estimate of 1) what % of users
> > can't suspend their laptops now and 2) of these, what % are helped by
> > suspend2, this thread is just handwaving...
>
> and 3) for what % of users, suspend2 will actually break it (bugs
> happen).
>
> Anyway it seems to be something like 1) 90% 2) 1% 3) .5%
And the source for your numbers is?....
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Tuesday 07 February 2006 19:23, Pavel Machek wrote:
> Hi!
>
> > > *Users* would not be at disadvantage, but, surprise, there's one
thing
> > > more important than users. Thats developers, and I can guarantee you
> > > that merging 14K lines of code just to delete them half a year later
> > > would drive them crazy.
> >
> > It would more be an ever-changing interface that would drive them
crazy. So
> > why don't we come up with an agreed method of starting a suspend and
> > starting a resume that they can use, without worrying about whether
> > they're getting swsusp, uswsusp or Suspend2? /sys/power/state seems the
> > obvious choice for this. An additional /sys entry could perhaps be used
to
> > modify which implementation is used when you echo disk
> /sys/power/state
> > - something like
> >
> > # cat /sys/power/disk_method
> > swsusp uswsusp suspend2
> > # echo uswsusp > /sys/power/disk_method
> > # echo > /sys/power/state
> >
> > Is there a big problem with that, which I've missed?
>
> Well, for _users_ method seems to be clicking "suspend" in KDE. For
> more experienced users it is powersave -U. And you are already
> distributing script to do suspend... Just hook suspend2 to the same
> gui stuff distributions already use.
The problem is that kpowersave, for example, doesn't provide any way to say
that you want to start the cycle by doing something other than echo
> /sys/power/state. They're apparently planning on changing it to support
suspend2, but should they have to (and why again for uswsusp?).
> Besides what you described can't work for uswsusp.
call_usermodehelper
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On ?t 07-02-06 19:36:45, Nigel Cunningham wrote:
> Hi.
>
> On Tuesday 07 February 2006 19:33, Pavel Machek wrote:
> > On Po 06-02-06 22:17:04, Lee Revell wrote:
> > > On Mon, 2006-02-06 at 22:01 -0500, Jim Crilly wrote:
> > > > With uswsusp it'll be more flexible in that you'll be able to use any
> > > > userland process or library to transform the image before storing it, but
> > > > the suspend and resume processes are going to be a lot more complicated.
> > > > For instance, how are you going to tell the kernel that you need the
> > > > uswsusp UI binary, /bin/gzip and /usr/bin/gpg to run after the rest of
> > > > userland has been frozen?
> > >
> > > Unless someone at least gives a rough estimate of 1) what % of users
> > > can't suspend their laptops now and 2) of these, what % are helped by
> > > suspend2, this thread is just handwaving...
> >
> > and 3) for what % of users, suspend2 will actually break it (bugs
> > happen).
> >
> > Anyway it seems to be something like 1) 90% 2) 1% 3) .5%
>
> And the source for your numbers is?....
Educated guess :-).
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
> > Well, for _users_ method seems to be clicking "suspend" in KDE. For
> > more experienced users it is powersave -U. And you are already
> > distributing script to do suspend... Just hook suspend2 to the same
> > gui stuff distributions already use.
>
> The problem is that kpowersave, for example, doesn't provide any way to say
> that you want to start the cycle by doing something other than echo
> > /sys/power/state. They're apparently planning on changing it to support
> suspend2, but should they have to (and why again for uswsusp?).
Fix kpowersave, then.
> > Besides what you described can't work for uswsusp.
>
> call_usermodehelper
No.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi!
> > > Personally I agree with you on suspend2, I think this is something that
> > > needed to Just Work yesterday, and every day it doesn't work we are
> > > losing users... but who am I to talk, I'm not the one who will have to
> > > maintain it.
> >
> > It does just work in mainline now. If it does not please open bug
> > account at bugzilla.kernel.org.
> >
> > If mainline swsusp is too slow for you, install uswsusp. If it is
> > still too slow for you, mail me a patch adding LZW to userland code
> > (should be easy).
>
> <horrified rebuke>
>
> Pavel!
>
> Responses like this are precisely why you're not the most popular kernel
> maintainer. Telling people to use beta (alpha?) code or fix it
I do not *want* to be the most popular maintainer. That is your place ;-).
> themselves
> (and then have their patches rejected by you) is no way to maintain a part
> of the kernel. Stop being a liability instead of an asset!
Ugh?
Lee is a programmer. He wants faster swsusp, and improving uswsusp is
currently best way to get that. It may be alpha/beta quality, but
someone has to start testing, and Lee should be good for that (played
with realtime kernels etc...). Actually it is in good enough state
that I'd like non-programmers to test it, too.
And yes, I'm a maintainer, and that means I have to reject bad
patches from time to time, too.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi!
> > > # cat /sys/power/disk_method
> > > swsusp uswsusp suspend2
> > > # echo uswsusp > /sys/power/disk_method
> > > # echo > /sys/power/state
> > >
> > > Is there a big problem with that, which I've missed?
> >
> > Userland suspend is driven by the suspending application which only calls
> > the kernel to do things it cannot do itself, like freezing (the other)
> > processes, snapshotting the system etc. We use the /dev/snapshot
> > device and the ioctl()s in there, so no sysfs files are needed for that.
> > It's independent and can coexist with the existing sysfs interface
> > just fine.
>
> Yes, but how are you going to get it started from (say) klaptop, which only
> knows "echo disk > /sys/power/state" as the way of starting a suspend? I'm
> suggesting that we create a means whereby the issue of how to start a
> cycle could be separated from what implementation is used to do the work.
> That is, a simple extension at the start of the disk specific code that
> starts swsusp, uswsusp or suspend2 depending upon what you want. Maybe I
> should just prepare a patch.
Please do not patch kernel for that.
Proper solution is probably creating s2disk program/script, and teach
kpowersave/klaptop/etc. to just use it. Then s2disk can detect best
method to use ... and then just do it. You already have suitable
script, but I'm not sure what its name is.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi again.
On Wednesday 08 February 2006 09:05, Pavel Machek wrote:
> Hi!
>
> > > > # cat /sys/power/disk_method
> > > > swsusp uswsusp suspend2
> > > > # echo uswsusp > /sys/power/disk_method
> > > > # echo > /sys/power/state
> > > >
> > > > Is there a big problem with that, which I've missed?
> > >
> > > Userland suspend is driven by the suspending application which only
calls
> > > the kernel to do things it cannot do itself, like freezing (the
other)
> > > processes, snapshotting the system etc. We use the /dev/snapshot
> > > device and the ioctl()s in there, so no sysfs files are needed for
that.
> > > It's independent and can coexist with the existing sysfs interface
> > > just fine.
> >
> > Yes, but how are you going to get it started from (say) klaptop, which
only
> > knows "echo disk > /sys/power/state" as the way of starting a suspend?
I'm
> > suggesting that we create a means whereby the issue of how to start a
> > cycle could be separated from what implementation is used to do the
work.
> > That is, a simple extension at the start of the disk specific code that
> > starts swsusp, uswsusp or suspend2 depending upon what you want. Maybe
I
> > should just prepare a patch.
>
> Please do not patch kernel for that.
>
> Proper solution is probably creating s2disk program/script, and teach
> kpowersave/klaptop/etc. to just use it. Then s2disk can detect best
> method to use ... and then just do it. You already have suitable
> script, but I'm not sure what its name is.
It occured to me as soon as I sent the last email (don't you hate that!)
that I'd forgotten the original impetus: backwards compatibility. If all
of the methods of suspending can be started with
"echo disk > /sys/power/state"
, your backwards compatability issue that you expressed concern about
earlier in this discussion is addressed. So, I'm not sure that dropping the
idea is the right thing to do.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On Wed, 2006-02-08 at 00:02 +0100, Pavel Machek wrote:
> Ugh?
>
> Lee is a programmer. He wants faster swsusp, and improving uswsusp is
> currently best way to get that. It may be alpha/beta quality, but
> someone has to start testing, and Lee should be good for that (played
> with realtime kernels etc...). Actually it is in good enough state
> that I'd like non-programmers to test it, too.
Unfortunately I won't have time to test this anytime soon, so I probably
should have kept quiet...
Lee
Hi,
On Wednesday 08 February 2006 00:02, Pavel Machek wrote:
> > > > Personally I agree with you on suspend2, I think this is something that
> > > > needed to Just Work yesterday, and every day it doesn't work we are
> > > > losing users... but who am I to talk, I'm not the one who will have to
> > > > maintain it.
> > >
> > > It does just work in mainline now. If it does not please open bug
> > > account at bugzilla.kernel.org.
> > >
> > > If mainline swsusp is too slow for you, install uswsusp. If it is
> > > still too slow for you, mail me a patch adding LZW to userland code
> > > (should be easy).
> >
> > <horrified rebuke>
> >
> > Pavel!
> >
> > Responses like this are precisely why you're not the most popular kernel
> > maintainer. Telling people to use beta (alpha?) code or fix it
>
> I do not *want* to be the most popular maintainer. That is your place ;-).
>
> > themselves
> > (and then have their patches rejected by you) is no way to maintain a part
> > of the kernel. Stop being a liability instead of an asset!
>
> Ugh?
>
> Lee is a programmer. He wants faster swsusp, and improving uswsusp is
> currently best way to get that. It may be alpha/beta quality, but
> someone has to start testing, and Lee should be good for that (played
> with realtime kernels etc...). Actually it is in good enough state
> that I'd like non-programmers to test it, too.
I'd rather like to wait with that until there's a howto. :-)
Greetings,
Rafael
On 02/08/06 12:02:45AM +0100, Pavel Machek wrote:
> Hi!
> Ugh?
>
> Lee is a programmer. He wants faster swsusp, and improving uswsusp is
> currently best way to get that. It may be alpha/beta quality, but
> someone has to start testing, and Lee should be good for that (played
> with realtime kernels etc...). Actually it is in good enough state
> that I'd like non-programmers to test it, too.
>
> And yes, I'm a maintainer, and that means I have to reject bad
> patches from time to time, too.
> Pavel
Best is a subjective term, I would say the 'best' way to get a swsusp
implementation that can save all of his caches and still suspend/resume
faster would be to just apply the Suspend2 patches and get on with
whatever he'd rather be doing since the work's already been done.
Jim.
> > > themselves
> > > (and then have their patches rejected by you) is no way to maintain a part
> > > of the kernel. Stop being a liability instead of an asset!
> >
> > Ugh?
> >
> > Lee is a programmer. He wants faster swsusp, and improving uswsusp is
> > currently best way to get that. It may be alpha/beta quality, but
> > someone has to start testing, and Lee should be good for that (played
> > with realtime kernels etc...). Actually it is in good enough state
> > that I'd like non-programmers to test it, too.
>
> I'd rather like to wait with that until there's a howto. :-)
Attached, now Lee or anyone can start hacking.
Suspend-to-disk HOWTO
~~~~~~~~~~~~~~~~~~~~
Copyright (C) 2006 Pavel Machek <[email protected]>
You'll need /dev/snapshot for these to work:
crw-r--r-- 1 root root 10, 231 Jan 13 21:21 /dev/snapshot
Then compile userspace tools in usual way. You'll need an -mm kernel
for now. To suspend-to-disk, run
./suspend /dev/<your_swap_partition>
. (There should be just one, for now.) Suspend is easy, resume is
slightly harder. Resume application has to be ran without any
filesystems mounted rw, and without any journalling filesystems
mounted at all, preferably from initrd (but read-only ext2 should do
the trick, too). Resume is then as easy as running
./resume /dev/<your_swap_partition>
. You probably want to create script that attempts to resume with
above command, and if that fails, fall back to init.
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hello.
On Wednesday 08 February 2006 09:02, Pavel Machek wrote:
> > > > Personally I agree with you on suspend2, I think this is something that
> > > > needed to Just Work yesterday, and every day it doesn't work we are
> > > > losing users... but who am I to talk, I'm not the one who will have to
> > > > maintain it.
> > >
> > > It does just work in mainline now. If it does not please open bug
> > > account at bugzilla.kernel.org.
> > >
> > > If mainline swsusp is too slow for you, install uswsusp. If it is
> > > still too slow for you, mail me a patch adding LZW to userland code
> > > (should be easy).
> >
> > <horrified rebuke>
> >
> > Pavel!
> >
> > Responses like this are precisely why you're not the most popular kernel
> > maintainer. Telling people to use beta (alpha?) code or fix it
>
> I do not *want* to be the most popular maintainer. That is your place ;-).
>
> > themselves
> > (and then have their patches rejected by you) is no way to maintain a part
> > of the kernel. Stop being a liability instead of an asset!
>
> Ugh?
>
> Lee is a programmer. He wants faster swsusp, and improving uswsusp is
> currently best way to get that. It may be alpha/beta quality, but
> someone has to start testing, and Lee should be good for that (played
> with realtime kernels etc...). Actually it is in good enough state
> that I'd like non-programmers to test it, too.
Ok. So Lee might be ok to test uswsusp. But this is your approach
regardless of who is emailing you. You consistently tell people to fix
problems themselves and send you a patch. That's not what a maintainer
should do. They're supposed to maintain, not get other people to do the
work. They're supposed to be helpful, not a source of anxiety. You might be
the maintainer of swsusp in name, but you're not in practice. Please, lift
your game!
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Wednesday 08 February 2006 09:05, Pavel Machek wrote:
> > > > # cat /sys/power/disk_method
> > > > swsusp uswsusp suspend2
> > > > # echo uswsusp > /sys/power/disk_method
> > > > # echo > /sys/power/state
> > > >
> > > > Is there a big problem with that, which I've missed?
> > >
> > > Userland suspend is driven by the suspending application which only calls
> > > the kernel to do things it cannot do itself, like freezing (the other)
> > > processes, snapshotting the system etc. We use the /dev/snapshot
> > > device and the ioctl()s in there, so no sysfs files are needed for that.
> > > It's independent and can coexist with the existing sysfs interface
> > > just fine.
> >
> > Yes, but how are you going to get it started from (say) klaptop, which only
> > knows "echo disk > /sys/power/state" as the way of starting a suspend? I'm
> > suggesting that we create a means whereby the issue of how to start a
> > cycle could be separated from what implementation is used to do the work.
> > That is, a simple extension at the start of the disk specific code that
> > starts swsusp, uswsusp or suspend2 depending upon what you want. Maybe I
> > should just prepare a patch.
>
> Please do not patch kernel for that.
>
> Proper solution is probably creating s2disk program/script, and teach
> kpowersave/klaptop/etc. to just use it. Then s2disk can detect best
> method to use ... and then just do it. You already have suitable
> script, but I'm not sure what its name is.
You have a good point there - the hibernate script is sufficient for the
task. Ok. I'll give up on this idea and consider it their problem for not
using what's provided already.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi!
> > Please do not patch kernel for that.
> >
> > Proper solution is probably creating s2disk program/script, and teach
> > kpowersave/klaptop/etc. to just use it. Then s2disk can detect best
> > method to use ... and then just do it. You already have suitable
> > script, but I'm not sure what its name is.
>
> It occured to me as soon as I sent the last email (don't you hate that!)
> that I'd forgotten the original impetus: backwards compatibility. If all
> of the methods of suspending can be started with
>
> "echo disk > /sys/power/state"
>
> , your backwards compatability issue that you expressed concern about
> earlier in this discussion is addressed. So, I'm not sure that dropping the
> idea is the right thing to do.
Yes, it probably is. echo > /sys/*/state needs to work for a while,
but we should really move everyone into running single command. Your
hibernate script probably good start. (I'd call it hibernate, not
hibernate.sh, so it does not *have* to be implemented in shell).
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Wednesday 08 February 2006 00:50, Pavel Machek wrote:
>
> > > > themselves
> > > > (and then have their patches rejected by you) is no way to maintain a part
> > > > of the kernel. Stop being a liability instead of an asset!
> > >
> > > Ugh?
> > >
> > > Lee is a programmer. He wants faster swsusp, and improving uswsusp is
> > > currently best way to get that. It may be alpha/beta quality, but
> > > someone has to start testing, and Lee should be good for that (played
> > > with realtime kernels etc...). Actually it is in good enough state
> > > that I'd like non-programmers to test it, too.
> >
> > I'd rather like to wait with that until there's a howto. :-)
>
> Attached, now Lee or anyone can start hacking.
>
> Suspend-to-disk HOWTO
> ~~~~~~~~~~~~~~~~~~~~
> Copyright (C) 2006 Pavel Machek <[email protected]>
>
>
> You'll need /dev/snapshot for these to work:
>
> crw-r--r-- 1 root root 10, 231 Jan 13 21:21 /dev/snapshot
>
> Then compile userspace tools in usual way. You'll need an -mm kernel
> for now. To suspend-to-disk, run
>
> ./suspend /dev/<your_swap_partition>
>
> . (There should be just one, for now.) Suspend is easy, resume is
> slightly harder. Resume application has to be ran without any
> filesystems mounted rw, and without any journalling filesystems
> mounted at all, preferably from initrd (but read-only ext2 should do
> the trick, too). Resume is then as easy as running
>
> ./resume /dev/<your_swap_partition>
>
> . You probably want to create script that attempts to resume with
> above command, and if that fails, fall back to init.
If it's run fron an initrd, it'll fall back automatically. Also you can set
the name of the resume partition in the header file swsusp.h and
you'll be able to use the tools without any command line
parameters (useful if you want to start resume from an initrd).
Besides, an -mm kernel is needed for this to work (preferrably
2.6.16-rc1-mm5, for now), and the CVS changes on a daily basis.
Greetings,
Rafael
Hi,
On Wednesday 08 February 2006 00:17, Nigel Cunningham wrote:
}-- snip --{
>
> It occured to me as soon as I sent the last email (don't you hate that!)
> that I'd forgotten the original impetus: backwards compatibility. If all
> of the methods of suspending can be started with
>
> "echo disk > /sys/power/state"
>
> , your backwards compatability issue that you expressed concern about
> earlier in this discussion is addressed. So, I'm not sure that dropping the
> idea is the right thing to do.
I'm not sure if the problem is real. If it turns out to be, it'll be solvable
in a couple of sane ways, so I don't think we need to worry about it
in advance.
I'd like the userland suspend to be an option and not a drop-in replacement
of swsusp or suspend2, so IMO it can be started in a different way.
Greetings,
Rafael
Hi,
On Wednesday 08 February 2006 00:11, Nigel Cunningham wrote:
> On Wednesday 08 February 2006 09:02, Pavel Machek wrote:
> > > > > Personally I agree with you on suspend2, I think this is something that
> > > > > needed to Just Work yesterday, and every day it doesn't work we are
> > > > > losing users... but who am I to talk, I'm not the one who will have to
> > > > > maintain it.
> > > >
> > > > It does just work in mainline now. If it does not please open bug
> > > > account at bugzilla.kernel.org.
> > > >
> > > > If mainline swsusp is too slow for you, install uswsusp. If it is
> > > > still too slow for you, mail me a patch adding LZW to userland code
> > > > (should be easy).
> > >
> > > <horrified rebuke>
> > >
> > > Pavel!
> > >
> > > Responses like this are precisely why you're not the most popular kernel
> > > maintainer. Telling people to use beta (alpha?) code or fix it
> >
> > I do not *want* to be the most popular maintainer. That is your place ;-).
> >
> > > themselves
> > > (and then have their patches rejected by you) is no way to maintain a part
> > > of the kernel. Stop being a liability instead of an asset!
> >
> > Ugh?
> >
> > Lee is a programmer. He wants faster swsusp, and improving uswsusp is
> > currently best way to get that. It may be alpha/beta quality, but
> > someone has to start testing, and Lee should be good for that (played
> > with realtime kernels etc...). Actually it is in good enough state
> > that I'd like non-programmers to test it, too.
>
> Ok. So Lee might be ok to test uswsusp. But this is your approach
> regardless of who is emailing you. You consistently tell people to fix
> problems themselves and send you a patch. That's not what a maintainer
> should do. They're supposed to maintain, not get other people to do the
> work. They're supposed to be helpful, not a source of anxiety. You might be
> the maintainer of swsusp in name, but you're not in practice. Please, lift
> your game!
I strongly disagree with this opinion. I don't think there's any problem with
Pavel, at least I haven't had any problems in communicating with him.
Moreover, I don't think the role of maintainer must be to actually write the
code. From my point of view Pavel is in the right place, because I need
someone to tell me if I'm going to do something stupid who knows the kernel
better than I do.
Furthermore, in many cases this is not Pavel who opposes your patches.
As we speak there is a discussion on linux-pm regarding a patch that you
have submitted and I'm sure you are following it. Please note that Pavel
hasn't spoken yet, but the patch has already been opposed by at least
two people. Is _this_ a Pavel's fault? No, it isn't.
Greetings,
Rafael
On Wednesday 08 February 2006 16:59, Rafael J. Wysocki wrote:
> Hi,
>
> On Wednesday 08 February 2006 00:11, Nigel Cunningham wrote:
> > On Wednesday 08 February 2006 09:02, Pavel Machek wrote:
> > > > > > Personally I agree with you on suspend2, I think this is something that
> > > > > > needed to Just Work yesterday, and every day it doesn't work we are
> > > > > > losing users... but who am I to talk, I'm not the one who will have to
> > > > > > maintain it.
> > > > >
> > > > > It does just work in mainline now. If it does not please open bug
> > > > > account at bugzilla.kernel.org.
> > > > >
> > > > > If mainline swsusp is too slow for you, install uswsusp. If it is
> > > > > still too slow for you, mail me a patch adding LZW to userland code
> > > > > (should be easy).
> > > >
> > > > <horrified rebuke>
> > > >
> > > > Pavel!
> > > >
> > > > Responses like this are precisely why you're not the most popular kernel
> > > > maintainer. Telling people to use beta (alpha?) code or fix it
> > >
> > > I do not *want* to be the most popular maintainer. That is your place ;-).
> > >
> > > > themselves
> > > > (and then have their patches rejected by you) is no way to maintain a part
> > > > of the kernel. Stop being a liability instead of an asset!
> > >
> > > Ugh?
> > >
> > > Lee is a programmer. He wants faster swsusp, and improving uswsusp is
> > > currently best way to get that. It may be alpha/beta quality, but
> > > someone has to start testing, and Lee should be good for that (played
> > > with realtime kernels etc...). Actually it is in good enough state
> > > that I'd like non-programmers to test it, too.
> >
> > Ok. So Lee might be ok to test uswsusp. But this is your approach
> > regardless of who is emailing you. You consistently tell people to fix
> > problems themselves and send you a patch. That's not what a maintainer
> > should do. They're supposed to maintain, not get other people to do the
> > work. They're supposed to be helpful, not a source of anxiety. You might be
> > the maintainer of swsusp in name, but you're not in practice. Please, lift
> > your game!
>
> I strongly disagree with this opinion. I don't think there's any problem with
> Pavel, at least I haven't had any problems in communicating with him.
You seem to be the only person around who gets on well with him. Please,
more people step up and tell me I'm wrong. I am only going off the mailing
list afterall, and not daily personal interaction of some other kind.
> Moreover, I don't think the role of maintainer must be to actually write the
> code. From my point of view Pavel is in the right place, because I need
> someone to tell me if I'm going to do something stupid who knows the kernel
> better than I do.
By definition, if they don't maintain code, their not a maintainer. If they
only tell someone that they're going to do something stupid, they're a
code reviewer.
> Furthermore, in many cases this is not Pavel who opposes your patches.
Other people have given feedback in the past that has been along the lines
of suggesting improvements / cleanups / whatever, but (feel free to correct
me) no one apart from him has written it off wholesale, told me I'm wasting
my time or the like.
I want to get on with Pavel, I really do. But it's very hard when, despite my
best efforts, trying to make allowances for possible misunderstandings and
the like, I never seem to hear a helpful word from him. It's always "No.".
"I don't want that.", and never (so far as I recall) "Here's how you could do
that better..", "The idea is ok but the implementation is broken because..." or
the like. Perhaps it is (as was said yesterday) just a cultural/language thing,
but I'm not sure.
> As we speak there is a discussion on linux-pm regarding a patch that you
> have submitted and I'm sure you are following it. Please note that Pavel
> hasn't spoken yet, but the patch has already been opposed by at least
> two people. Is _this_ a Pavel's fault? No, it isn't.
I haven't seen any replies apart from yours so far. Perhaps there's something
wrong with my mail delivery :(. I'll check the archives.
Nigel
> Greetings,
> Rafael
>
>
>
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi!
[I should probably left this reply to Rafael, but...]
> > > Ok. So Lee might be ok to test uswsusp. But this is your approach
> > > regardless of who is emailing you. You consistently tell people to fix
> > > problems themselves and send you a patch. That's not what a maintainer
> > > should do. They're supposed to maintain, not get other people to do the
> > > work. They're supposed to be helpful, not a source of anxiety. You might be
> > > the maintainer of swsusp in name, but you're not in practice. Please, lift
> > > your game!
> >
> > I strongly disagree with this opinion. I don't think there's any problem with
> > Pavel, at least I haven't had any problems in communicating with him.
>
> You seem to be the only person around who gets on well with him. Please,
> more people step up and tell me I'm wrong. I am only going off the mailing
> list afterall, and not daily personal interaction of some other
> kind.
Well, on the other hand you are the only person that really has
problems with me.
> > Moreover, I don't think the role of maintainer must be to actually write the
> > code. From my point of view Pavel is in the right place, because I need
> > someone to tell me if I'm going to do something stupid who knows the kernel
> > better than I do.
>
> By definition, if they don't maintain code, their not a maintainer. If they
> only tell someone that they're going to do something stupid, they're a
> code reviewer.
You seem to be using different definition of maintainer than rest of
the world.
> > Furthermore, in many cases this is not Pavel who opposes your patches.
>
> Other people have given feedback in the past that has been along the lines
> of suggesting improvements / cleanups / whatever, but (feel free to correct
> me) no one apart from him has written it off wholesale, told me I'm wasting
> my time or the like.
>
> I want to get on with Pavel, I really do. But it's very hard when, despite my
> best efforts, trying to make allowances for possible misunderstandings and
> the like, I never seem to hear a helpful word from him. It's always "No.".
> "I don't want that.", and never (so far as I recall) "Here's how you could do
> that better..", "The idea is ok but the implementation is broken because..." or
> the like. Perhaps it is (as was said yesterday) just a cultural/language thing,
> but I'm not sure.
If I rephrase my comments as:
"The idea is okay, but the implementation is broken, because it does
too much stuff in the kernel."
and
"Here's how you could do that better; take a look at latest -mm and
use facilities it provides to push most of suspend2 code into
userland."
...will that help?
> > As we speak there is a discussion on linux-pm regarding a patch that you
> > have submitted and I'm sure you are following it. Please note that Pavel
> > hasn't spoken yet, but the patch has already been opposed by at least
> > two people. Is _this_ a Pavel's fault? No, it isn't.
>
> I haven't seen any replies apart from yours so far. Perhaps there's something
> wrong with my mail delivery :(. I'll check the archives.
Oh... did not seen that mail thread. Please cc: me on suspend-related
stuff.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi!
> > Suspend-to-disk HOWTO
> > ~~~~~~~~~~~~~~~~~~~~
> > Copyright (C) 2006 Pavel Machek <[email protected]>
> >
> >
> > You'll need /dev/snapshot for these to work:
> >
> > crw-r--r-- 1 root root 10, 231 Jan 13 21:21 /dev/snapshot
> > Then compile userspace tools in usual way. You'll need an -mm kernel
> > for now. To suspend-to-disk, run
I actually added -mm warning here.
> > ./suspend /dev/<your_swap_partition>
> >
> > . (There should be just one, for now.) Suspend is easy, resume is
> > slightly harder. Resume application has to be ran without any
> > filesystems mounted rw, and without any journalling filesystems
> > mounted at all, preferably from initrd (but read-only ext2 should do
> > the trick, too). Resume is then as easy as running
> >
> > ./resume /dev/<your_swap_partition>
> >
> > . You probably want to create script that attempts to resume with
> > above command, and if that fails, fall back to init.
>
> If it's run fron an initrd, it'll fall back automatically. Also you can set
> the name of the resume partition in the header file swsusp.h and
> you'll be able to use the tools without any command line
> parameters (useful if you want to start resume from an initrd).
I know a little about initrd. I've just commited HOWTO file, can you
edit it to describe that?
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi,
On Wednesday 08 February 2006 09:28, Pavel Machek wrote:
> > > Suspend-to-disk HOWTO
> > > ~~~~~~~~~~~~~~~~~~~~
> > > Copyright (C) 2006 Pavel Machek <[email protected]>
> > >
> > >
> > > You'll need /dev/snapshot for these to work:
> > >
> > > crw-r--r-- 1 root root 10, 231 Jan 13 21:21 /dev/snapshot
>
>
> > > Then compile userspace tools in usual way. You'll need an -mm kernel
> > > for now. To suspend-to-disk, run
>
> I actually added -mm warning here.
Oh, I didn't notice, sorry.
> > > ./suspend /dev/<your_swap_partition>
> > >
> > > . (There should be just one, for now.) Suspend is easy, resume is
> > > slightly harder. Resume application has to be ran without any
> > > filesystems mounted rw, and without any journalling filesystems
> > > mounted at all, preferably from initrd (but read-only ext2 should do
> > > the trick, too). Resume is then as easy as running
> > >
> > > ./resume /dev/<your_swap_partition>
> > >
> > > . You probably want to create script that attempts to resume with
> > > above command, and if that fails, fall back to init.
> >
> > If it's run fron an initrd, it'll fall back automatically. Also you can set
> > the name of the resume partition in the header file swsusp.h and
> > you'll be able to use the tools without any command line
> > parameters (useful if you want to start resume from an initrd).
>
> I know a little about initrd. I've just commited HOWTO file, can you
> edit it to describe that?
OK, I will, but when I have some time for that (today in the night, probably).
Greetings,
Rafael
Hi,
On Wednesday 08 February 2006 08:33, Nigel Cunningham wrote:
> On Wednesday 08 February 2006 16:59, Rafael J. Wysocki wrote:
> > On Wednesday 08 February 2006 00:11, Nigel Cunningham wrote:
> > > On Wednesday 08 February 2006 09:02, Pavel Machek wrote:
}-- snip --{
> > > > Lee is a programmer. He wants faster swsusp, and improving uswsusp is
> > > > currently best way to get that. It may be alpha/beta quality, but
> > > > someone has to start testing, and Lee should be good for that (played
> > > > with realtime kernels etc...). Actually it is in good enough state
> > > > that I'd like non-programmers to test it, too.
> > >
> > > Ok. So Lee might be ok to test uswsusp. But this is your approach
> > > regardless of who is emailing you. You consistently tell people to fix
> > > problems themselves and send you a patch. That's not what a maintainer
> > > should do. They're supposed to maintain, not get other people to do the
> > > work. They're supposed to be helpful, not a source of anxiety. You might be
> > > the maintainer of swsusp in name, but you're not in practice. Please, lift
> > > your game!
> >
> > I strongly disagree with this opinion. I don't think there's any problem with
> > Pavel, at least I haven't had any problems in communicating with him.
>
> You seem to be the only person around who gets on well with him.
Well, that's probably because I always do my best to be nice and follow the
rules that Pavel sets. I post patches to modify the existing code and not to
replace it top-down. I keep them as compact as reasonably possible
and focus on one thing at a time. I remove the parts that Pavel and other
people don't like or I try to modify these parts to be more acceptable.
Etc. This is not _that_ difficult.
> Please, more people step up and tell me I'm wrong. I am only going off the
> mailing list afterall, and not daily personal interaction of some other kind.
>
> > Moreover, I don't think the role of maintainer must be to actually write the
> > code. From my point of view Pavel is in the right place, because I need
> > someone to tell me if I'm going to do something stupid who knows the kernel
> > better than I do.
>
> By definition, if they don't maintain code, their not a maintainer. If they
> only tell someone that they're going to do something stupid, they're a
> code reviewer.
Well, this is your opinion.
In my opinion a maintainer need not be a developer. The dictionary definition
of "to maintain" is "to keep a road, machine, building, etc. in good condition"
(http://dictionary.cambridge.org/define.asp?key=48204&dict=CALD)
which need not impy any development.
Greetings,
Rafael
There are some questions I have while looking at this HOWTO,
which I think should be answered there:
Pavel Machek <[email protected]> wrote:
> Suspend-to-disk HOWTO
> ~~~~~~~~~~~~~~~~~~~~
[...]
> ./suspend /dev/<your_swap_partition>
Does it need to be mounted (so it possibly gets filled and thereby unusable),
or can it be a mkswapped partition?
Can it even be a swap-file? Probably not, unless you want to resume by
ro-nojournalreplay-mounting the corresponding partition.
How big does it have to be, compared to the RAM? As big + n? Bigger? BIGGER?
--
Ich danke GMX daf?r, die Verwendung meiner Adressen mittels per SPF
verbreiteten L?gen zu sabotieren.
Hi,
On Wednesday 08 February 2006 14:23, Bodo Eggert wrote:
> There are some questions I have while looking at this HOWTO,
> which I think should be answered there:
>
> Pavel Machek <[email protected]> wrote:
>
> > Suspend-to-disk HOWTO
> > ~~~~~~~~~~~~~~~~~~~~
> [...]
> > ./suspend /dev/<your_swap_partition>
>
> Does it need to be mounted (so it possibly gets filled and thereby unusable),
> or can it be a mkswapped partition?
A mkswapped one will do. Actually a mounted one will do either and the data
on it won't get damaged.
> Can it even be a swap-file?
No.
> Probably not, unless you want to resume by ro-nojournalreplay-mounting the
> corresponding partition.
>
> How big does it have to be, compared to the RAM? As big + n? Bigger? BIGGER?
May be smaller. You'll need at most 1/2 of your RAM size of free space on it.
I'll put the answers in the howto, thanks for the hint.
Greetings,
Rafael
Hi.
On Wednesday 08 February 2006 20:03, Rafael J. Wysocki wrote:
> Well, that's probably because I always do my best to be nice and follow
the
> rules that Pavel sets. I post patches to modify the existing code and
not to
> replace it top-down. I keep them as compact as reasonably possible
> and focus on one thing at a time. I remove the parts that Pavel and
other
> people don't like or I try to modify these parts to be more acceptable.
> Etc. This is not _that_ difficult.
Yeah. I guess those are the differences. Thanks for putting it so clearly.
Well, we're obviously not getting anywhere while I'm trying to redesign the
existing code, so I guess I'll just go back to finishing the git tree and
leave anyone who wants to use it to use it.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi,
On Wednesday 08 February 2006 15:23, Rafael J. Wysocki wrote:
> On Wednesday 08 February 2006 14:23, Bodo Eggert wrote:
> > There are some questions I have while looking at this HOWTO,
> > which I think should be answered there:
> >
> > Pavel Machek <[email protected]> wrote:
> >
> > > Suspend-to-disk HOWTO
> > > ~~~~~~~~~~~~~~~~~~~~
> > [...]
> > > ./suspend /dev/<your_swap_partition>
> >
> > Does it need to be mounted (so it possibly gets filled and thereby unusable),
> > or can it be a mkswapped partition?
>
> A mkswapped one will do.
Sorry, that's not true. For now the tools only work with mounted swap
partitions, but they use the kernel to allocate free swap pages from them.
Greetings,
Rafael
Hi.
On Tuesday 07 February 2006 01:13, Rafael J. Wysocki wrote:
> > > I like the chroot idea too.
> >
> > You're making this too complicated. Just require that the userspace program
> > does all it's file opening etc prior to telling kernelspace to do
> > anything. Then clearly document the requirement. If someone breaks the
> > rule, it is their problem, and their testing should show their
> > foolishness. We have done a similar thing in the Suspend2 userspace user
> > interface code, and it works fine.
>
> Unfortunately I'd like to open at least one device file after freeze, for a
> technical reason that probably does not exist in suspend2, so I need a
> temporary filesystem anyway. Chrooting to it is just a cake.
Does the open need to be delayed until after the freeze?
> [BTW, we have the list [email protected] we'd like
> to be a place for discussing the userspace suspend issues. If you could
> subscribe to it, we'd be able to move the discussion there.]
Will do. Sorry for the slow reply - had a bogus mail filtering rule.
Nigel
Hi!
> On Wednesday 08 February 2006 20:03, Rafael J. Wysocki wrote:
> > Well, that's probably because I always do my best to be nice and follow
> the
> > rules that Pavel sets. I post patches to modify the existing code and
> not to
> > replace it top-down. I keep them as compact as reasonably possible
> > and focus on one thing at a time. I remove the parts that Pavel and
> other
> > people don't like or I try to modify these parts to be more acceptable.
> > Etc. This is not _that_ difficult.
>
> Yeah. I guess those are the differences. Thanks for putting it so clearly.
> Well, we're obviously not getting anywhere while I'm trying to redesign the
> existing code, so I guess I'll just go back to finishing the git tree and
> leave anyone who wants to use it to use it.
At one point you said you'd like to work with us, and earlier in the
threads you stated that porting suspend2 to userland should be easy.
[I do not think that putting suspend2 into git is useful thing to
do. Of course, it is your option; but it seems to me that people
likely to use suspend2 are not the kind of people that use git.]
It would be very helpful if you could install uswsusp, then try to
make suspend2 run in userland on top of uswsusp interface. Not
everything will be possible that way, but it most of features should
be doable that way. I'd hate to code yet another splashscreen code,
for example...
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hello.
On Thursday 09 February 2006 10:06, Pavel Machek wrote:
> > On Wednesday 08 February 2006 20:03, Rafael J. Wysocki wrote:
> > > Well, that's probably because I always do my best to be nice and follow
> > the
> > > rules that Pavel sets. I post patches to modify the existing code and
> > not to
> > > replace it top-down. I keep them as compact as reasonably possible
> > > and focus on one thing at a time. I remove the parts that Pavel and
> > other
> > > people don't like or I try to modify these parts to be more acceptable.
> > > Etc. This is not _that_ difficult.
> >
> > Yeah. I guess those are the differences. Thanks for putting it so clearly.
> > Well, we're obviously not getting anywhere while I'm trying to redesign the
> > existing code, so I guess I'll just go back to finishing the git tree and
> > leave anyone who wants to use it to use it.
>
> At one point you said you'd like to work with us, and earlier in the
> threads you stated that porting suspend2 to userland should be easy.
>
> [I do not think that putting suspend2 into git is useful thing to
> do. Of course, it is your option; but it seems to me that people
> likely to use suspend2 are not the kind of people that use git.]
>
> It would be very helpful if you could install uswsusp, then try to
> make suspend2 run in userland on top of uswsusp interface. Not
> everything will be possible that way, but it most of features should
> be doable that way. I'd hate to code yet another splashscreen code,
> for example...
I've begun briefly to have a look at this.
Part of the problem I have, both with doing incremental patches for swsusp
and with doing a userspace version, is that some of the fundamentals are
redesigned in suspend2. The most important of these is that we store the
metadata in bitmaps (for pageflags) and extents (for storage) instead of
pbes. Do you have thoughts on how to overcome that issue? Are you
willing, for example, to do work on switching swsusp to use a different
method of storing its data?
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Good morning ;-).
> > At one point you said you'd like to work with us, and earlier in the
> > threads you stated that porting suspend2 to userland should be easy.
> >
> > [I do not think that putting suspend2 into git is useful thing to
> > do. Of course, it is your option; but it seems to me that people
> > likely to use suspend2 are not the kind of people that use git.]
> >
> > It would be very helpful if you could install uswsusp, then try to
> > make suspend2 run in userland on top of uswsusp interface. Not
> > everything will be possible that way, but it most of features should
> > be doable that way. I'd hate to code yet another splashscreen code,
> > for example...
>
> I've begun briefly to have a look at this.
>
> Part of the problem I have, both with doing incremental patches for swsusp
> and with doing a userspace version, is that some of the fundamentals are
> redesigned in suspend2. The most important of these is that we store the
> metadata in bitmaps (for pageflags) and extents (for storage) instead of
> pbes. Do you have thoughts on how to overcome that issue? Are you
> willing, for example, to do work on switching swsusp to use a different
> method of storing its data?
Any changes to userspace are a fair game. OTOH kernel provides linear
image to be saved to userspace, and what it uses internally should not
be important to userland parts. (And Rafael did some changes in that
area to make it more effective, IIRC).
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi,
On Thursday 09 February 2006 10:25, Pavel Machek wrote:
> Good morning ;-).
>
> > > At one point you said you'd like to work with us, and earlier in the
> > > threads you stated that porting suspend2 to userland should be easy.
> > >
> > > [I do not think that putting suspend2 into git is useful thing to
> > > do. Of course, it is your option; but it seems to me that people
> > > likely to use suspend2 are not the kind of people that use git.]
> > >
> > > It would be very helpful if you could install uswsusp, then try to
> > > make suspend2 run in userland on top of uswsusp interface. Not
> > > everything will be possible that way, but it most of features should
> > > be doable that way. I'd hate to code yet another splashscreen code,
> > > for example...
> >
> > I've begun briefly to have a look at this.
> >
> > Part of the problem I have, both with doing incremental patches for swsusp
> > and with doing a userspace version, is that some of the fundamentals are
> > redesigned in suspend2. The most important of these is that we store the
> > metadata in bitmaps (for pageflags) and extents (for storage) instead of
> > pbes. Do you have thoughts on how to overcome that issue? Are you
> > willing, for example, to do work on switching swsusp to use a different
> > method of storing its data?
>
> Any changes to userspace are a fair game. OTOH kernel provides linear
> image to be saved to userspace, and what it uses internally should not
> be important to userland parts. (And Rafael did some changes in that
> area to make it more effective, IIRC).
Yes. The code is now split into the part that handles the snapshot image
(in snapshot.c) and the part that writes/reads it to swap (in swap.c). [I'm
referring to recent -mm kernels.]
The access to the snapshot image is provided via the functions
snapshot_write_next() and snapshot_read_next() that are called by the
code in swap.c and may be used by the user space tools via the
interface in user.c. In principle it ought to be possible to plug
something else instead of the code in snapshot.c without
breaking the rest.
Greetings,
Rafael
Hi.
On Thursday 09 February 2006 23:22, Rafael J. Wysocki wrote:
> > > I've begun briefly to have a look at this.
> > >
> > > Part of the problem I have, both with doing incremental patches for
> > > swsusp and with doing a userspace version, is that some of the
> > > fundamentals are redesigned in suspend2. The most important of these is
> > > that we store the metadata in bitmaps (for pageflags) and extents (for
> > > storage) instead of pbes. Do you have thoughts on how to overcome that
> > > issue? Are you willing, for example, to do work on switching swsusp to
> > > use a different method of storing its data?
> >
> > Any changes to userspace are a fair game. OTOH kernel provides linear
> > image to be saved to userspace, and what it uses internally should not
> > be important to userland parts. (And Rafael did some changes in that
> > area to make it more effective, IIRC).
>
> Yes. The code is now split into the part that handles the snapshot image
> (in snapshot.c) and the part that writes/reads it to swap (in swap.c). [I'm
> referring to recent -mm kernels.]
>
> The access to the snapshot image is provided via the functions
> snapshot_write_next() and snapshot_read_next() that are called by the
> code in swap.c and may be used by the user space tools via the
> interface in user.c. In principle it ought to be possible to plug
> something else instead of the code in snapshot.c without
> breaking the rest.
So, what is the answer then? If I submitted patches to provide the possibility
of separating LRU pages into a separate stream of pages to be read/written,
would it have any chance of getting merged? (Along with other patches to make
writing a full image of memory possible).
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Thursday 09 February 2006 19:25, Pavel Machek wrote:
> Good morning ;-).
>
> > > At one point you said you'd like to work with us, and earlier in the
> > > threads you stated that porting suspend2 to userland should be easy.
> > >
> > > [I do not think that putting suspend2 into git is useful thing to
> > > do. Of course, it is your option; but it seems to me that people
> > > likely to use suspend2 are not the kind of people that use git.]
> > >
> > > It would be very helpful if you could install uswsusp, then try to
> > > make suspend2 run in userland on top of uswsusp interface. Not
> > > everything will be possible that way, but it most of features should
> > > be doable that way. I'd hate to code yet another splashscreen code,
> > > for example...
> >
> > I've begun briefly to have a look at this.
> >
> > Part of the problem I have, both with doing incremental patches for
> > swsusp and with doing a userspace version, is that some of the
> > fundamentals are redesigned in suspend2. The most important of these is
> > that we store the metadata in bitmaps (for pageflags) and extents (for
> > storage) instead of pbes. Do you have thoughts on how to overcome that
> > issue? Are you willing, for example, to do work on switching swsusp to
> > use a different method of storing its data?
>
> Any changes to userspace are a fair game. OTOH kernel provides linear
> image to be saved to userspace, and what it uses internally should not
> be important to userland parts. (And Rafael did some changes in that
> area to make it more effective, IIRC).
What about providing the possibility of using the 2 pagesets I use at the
moment? I'm not suggesting it should be compulsory, but perhaps an ioctl to
say "I want to save a Suspend2 style image"?
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi!
> > > I've begun briefly to have a look at this.
> > >
> > > Part of the problem I have, both with doing incremental patches for
> > > swsusp and with doing a userspace version, is that some of the
> > > fundamentals are redesigned in suspend2. The most important of these is
> > > that we store the metadata in bitmaps (for pageflags) and extents (for
> > > storage) instead of pbes. Do you have thoughts on how to overcome that
> > > issue? Are you willing, for example, to do work on switching swsusp to
> > > use a different method of storing its data?
> >
> > Any changes to userspace are a fair game. OTOH kernel provides linear
> > image to be saved to userspace, and what it uses internally should not
> > be important to userland parts. (And Rafael did some changes in that
> > area to make it more effective, IIRC).
>
> What about providing the possibility of using the 2 pagesets I use at the
> moment? I'm not suggesting it should be compulsory, but perhaps an ioctl to
> say "I want to save a Suspend2 style image"?
I'd prefer to get the low-hanging fruits, first. LZF compression seems
like a first target.
Of course, adding ioctl to do suspend2-style snapshot is possible, but
I fear it will be too intrusive, and would prefer to do it after
getting the simple stuff done.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi!
> > > Any changes to userspace are a fair game. OTOH kernel provides linear
> > > image to be saved to userspace, and what it uses internally should not
> > > be important to userland parts. (And Rafael did some changes in that
> > > area to make it more effective, IIRC).
> >
> > Yes. The code is now split into the part that handles the snapshot image
> > (in snapshot.c) and the part that writes/reads it to swap (in swap.c). [I'm
> > referring to recent -mm kernels.]
> >
> > The access to the snapshot image is provided via the functions
> > snapshot_write_next() and snapshot_read_next() that are called by the
> > code in swap.c and may be used by the user space tools via the
> > interface in user.c. In principle it ought to be possible to plug
> > something else instead of the code in snapshot.c without
> > breaking the rest.
>
> So, what is the answer then? If I submitted patches to provide the possibility
> of separating LRU pages into a separate stream of pages to be read/written,
> would it have any chance of getting merged? (Along with other patches to make
> writing a full image of memory possible).
Could we do the other stuff, first, please? Userland
LZF/encryption/progress should be easy to do, and doing that should
teach us how to cooperate.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi.
On Friday 10 February 2006 09:34, Pavel Machek wrote:
> Hi!
>
> > > > Any changes to userspace are a fair game. OTOH kernel provides linear
> > > > image to be saved to userspace, and what it uses internally should
> > > > not be important to userland parts. (And Rafael did some changes in
> > > > that area to make it more effective, IIRC).
> > >
> > > Yes. The code is now split into the part that handles the snapshot
> > > image (in snapshot.c) and the part that writes/reads it to swap (in
> > > swap.c). [I'm referring to recent -mm kernels.]
> > >
> > > The access to the snapshot image is provided via the functions
> > > snapshot_write_next() and snapshot_read_next() that are called by the
> > > code in swap.c and may be used by the user space tools via the
> > > interface in user.c. In principle it ought to be possible to plug
> > > something else instead of the code in snapshot.c without
> > > breaking the rest.
> >
> > So, what is the answer then? If I submitted patches to provide the
> > possibility of separating LRU pages into a separate stream of pages to be
> > read/written, would it have any chance of getting merged? (Along with
> > other patches to make writing a full image of memory possible).
>
> Could we do the other stuff, first, please? Userland
> LZF/encryption/progress should be easy to do, and doing that should
> teach us how to cooperate.
The problem I have with doing that is that it makes more work. Adding support
for multiple sets of pages is a more fundamental change, and so should be
done earlier. Let me use an analogy from evolutionary theory (yes, I think
evolution is flawed, but let's ignore that for the mo). If you were trying to
image the steps by which an amoeba became a human being, would you put the
devlopment of the cardio-vascular system before the development of eye sight?
Making eye sight work (if it was at all possible) without a cardio vascular
system would result in a fundamentally different design for the eye than if
you did the cario-vascular system first. Changing the eye once the
cardio-vascular system was in would be a huge redevelopment, and a huge pain.
For the same reasons, I think that if support for 2 pagesets was going to be
put in an implementation it should be done as early as possible. Likewise for
reworking the method by which data is stored (I say, thinking of bitmaps vs
pbes).
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi,
On Friday 10 February 2006 01:08, Nigel Cunningham wrote:
> On Friday 10 February 2006 09:34, Pavel Machek wrote:
> > > > > Any changes to userspace are a fair game. OTOH kernel provides linear
> > > > > image to be saved to userspace, and what it uses internally should
> > > > > not be important to userland parts. (And Rafael did some changes in
> > > > > that area to make it more effective, IIRC).
> > > >
> > > > Yes. The code is now split into the part that handles the snapshot
> > > > image (in snapshot.c) and the part that writes/reads it to swap (in
> > > > swap.c). [I'm referring to recent -mm kernels.]
> > > >
> > > > The access to the snapshot image is provided via the functions
> > > > snapshot_write_next() and snapshot_read_next() that are called by the
> > > > code in swap.c and may be used by the user space tools via the
> > > > interface in user.c. In principle it ought to be possible to plug
> > > > something else instead of the code in snapshot.c without
> > > > breaking the rest.
> > >
> > > So, what is the answer then? If I submitted patches to provide the
> > > possibility of separating LRU pages into a separate stream of pages to be
> > > read/written, would it have any chance of getting merged? (Along with
> > > other patches to make writing a full image of memory possible).
> >
> > Could we do the other stuff, first, please? Userland
> > LZF/encryption/progress should be easy to do, and doing that should
> > teach us how to cooperate.
>
> The problem I have with doing that is that it makes more work. Adding support
> for multiple sets of pages is a more fundamental change, and so should be
> done earlier. Let me use an analogy from evolutionary theory (yes, I think
> evolution is flawed, but let's ignore that for the mo). If you were trying to
> image the steps by which an amoeba became a human being, would you put the
> devlopment of the cardio-vascular system before the development of eye sight?
> Making eye sight work (if it was at all possible) without a cardio vascular
> system would result in a fundamentally different design for the eye than if
> you did the cario-vascular system first. Changing the eye once the
> cardio-vascular system was in would be a huge redevelopment, and a huge pain.
> For the same reasons, I think that if support for 2 pagesets was going to be
> put in an implementation it should be done as early as possible. Likewise for
> reworking the method by which data is stored (I say, thinking of bitmaps vs
> pbes).
The evolution theory assumes that features are not planned and are developed
"as needed", but you know you'll need the feature at some point and you can
design for it without actually implementing it.
Now in swsusp we do something like this:
freeze()
atomic_snapshot()
save_image() (=> snapshot_read() in a loop)
power_down()
If I understand it correctly, you'd like to do something like this:
freeze()
save_LRU() (=> snapshot_read() in a loop)
atomic_snapshot()
save_image() (=> snapshot_read() in a loop)
power_down()
Suppose there are no LRU pages to save (unrealistic, but helpful).
In such a case save_LRU() does nothing and your procedure is identical
to ours. Thus you can assume, for now, that you always have 0 LRU pages
to save, put placeholders wherever needed and go on. Later on you'll be
able to replace the placeholders with something actually useful.
Further, we can assume that snapshot_read() can only be called before
atomic_snapshot() for saving LRU pages and no changes to the interface
will be needed.
Greetings,
Rafael
Hi!
So another flamewar is over, good. I even received one apology ;-),
and probably should have sent some apologies, too...
Anyway, it means that suspend is still quite a hot topic, and that is
good. (Linus said that suspend-to-disk is basically for people that
can't get suspend-to-RAM to work, and after I got suspend-to-RAM to
work reliably here, I can see his point).
Anyway, uswsusp project needs your help. It is basically working, see
http://www.sf.net/projects/suspend , and it is already faster then in-kernel
version. How you could help?
* testing is useful at this point. Few confirmations that it works in
different configurations would make us feel warm and fuzzy.
* documentation improvements, and small scripts. Having script that
prepares initrd would be nice, for example.
* having someone to maintain suspend.sf.net web pages / release CVS
snapshot as package would help, too.
* userspace code improvements. Encryption, LZW and graphical progress
should be reasonably easy to do. There's some tricky stuff, if you
prefer -- support for swap files and normal files would help,
too. Plus I guess everyone has their favourite feature...
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Saturday 11 February 2006 00:35, Pavel Machek wrote:
> So another flamewar is over, good. I even received one apology ;-),
> and probably should have sent some apologies, too...
[...]
> version. How you could help?
>
> * testing is useful at this point. Few confirmations that it works in
> different configurations would make us feel warm and fuzzy.
>
> * documentation improvements, and small scripts. Having script that
> prepares initrd would be nice, for example.
>
> * having someone to maintain suspend.sf.net web pages / release CVS
> snapshot as package would help, too.
>
> * userspace code improvements. Encryption, LZW and graphical progress
> should be reasonably easy to do. There's some tricky stuff, if you
> prefer -- support for swap files and normal files would help,
> too. Plus I guess everyone has their favourite feature...
That all makes sense.
To make uswsusp a success you need it tested [T], supporting scripts [S],
someone [B] who puts work in the webpages [W] with decent documentation [D],
and a bunch of spiffy features [F].
[T] * http://wiki.suspend2.net/FeatureUserRegister
* http://www.suspend2.net/lists
[S] http://www.suspend2.net/downloads/all/hibernate-script-1.12.tar.gz
[B] Bernard Blackham, [email protected]
[W] http://www.suspend2.net
[D] * http://www.suspend2.net/links
* http://www.suspend2.net/HOWTO
* http://www.suspend2.net/FAQ
[F] http://www.suspend2.net/features
I, as a contributors to suspend2, have been working on all that stuff for
about two-and-a-half years, and it makes me really sad to see that someone in
a position to make a decision towards progress wants to start that whole
process all over, rather than acknowledging the existance of a technical
superior solution - including a well-functioning supporting community - and
working towards getting this solution available for a wider audience.
Judging from experience, uswsusp is probably two years away until it can even
come close to what suspend2 offers right now, and that would be the ideal
case of having a lot of people helping in the progress, involving being
actively involved and dedicated to fixing problems.
--
sebas
http://www.kde.nl | http://vizZzion.org | GPG Key ID: 9119 0EF9
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Anything cut to length will be too short.
On So 11-02-06 01:16:51, Sebastian K?gler wrote:
> On Saturday 11 February 2006 00:35, Pavel Machek wrote:
> > So another flamewar is over, good. I even received one apology ;-),
> > and probably should have sent some apologies, too...
> [...]
> > version. How you could help?
> >
> > * testing is useful at this point. Few confirmations that it works in
> > different configurations would make us feel warm and fuzzy.
> >
> > * documentation improvements, and small scripts. Having script that
> > prepares initrd would be nice, for example.
> >
> > * having someone to maintain suspend.sf.net web pages / release CVS
> > snapshot as package would help, too.
> >
> > * userspace code improvements. Encryption, LZW and graphical progress
> > should be reasonably easy to do. There's some tricky stuff, if you
> > prefer -- support for swap files and normal files would help,
> > too. Plus I guess everyone has their favourite feature...
>
> That all makes sense.
>
> To make uswsusp a success you need it tested [T], supporting scripts [S],
> someone [B] who puts work in the webpages [W] with decent documentation [D],
> and a bunch of spiffy features [F].
>
> [T] * http://wiki.suspend2.net/FeatureUserRegister
> * http://www.suspend2.net/lists
> [S] http://www.suspend2.net/downloads/all/hibernate-script-1.12.tar.gz
> [B] Bernard Blackham, [email protected]
> [W] http://www.suspend2.net
> [D] * http://www.suspend2.net/links
> * http://www.suspend2.net/HOWTO
> * http://www.suspend2.net/FAQ
> [F] http://www.suspend2.net/features
>
> I, as a contributors to suspend2, have been working on all that stuff for
> about two-and-a-half years, and it makes me really sad to see that
> someone in
If you think current situation makes me happy... think again.
> a position to make a decision towards progress wants to start that whole
> process all over, rather than acknowledging the existance of a
> technical
We don't have to start all over. It should be possible to port most of
suspend2 into userspace...
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Feb 10, 2006, at 18:35, Pavel Machek wrote:
> Anyway, it means that suspend is still quite a hot topic, and that
> is good. (Linus said that suspend-to-disk is basically for people
> that can't get suspend-to-RAM to work, and after I got suspend-to-
> RAM to work reliably here, I can see his point).
I completely agree. My Mac PowerBook has had suspend-to-RAM for a
long time; I shut the lid and about 3 seconds later it's asleep, open
it and 3 seconds later it's awake. Leave it sleeping for a week on a
full charge, come back to find it still asleep. I can even put it to
sleep, remove a drained battery and put in a fresh one (it has a
small internal 2-minute RAM battery), then wake it up and resume
work. I'm curious though, what proportion of laptop hardware
actually has support for suspend-to-RAM? (including hardware for
which linux does not yet have support). What percent of that
hardware _does_ have Linux support?
Cheers,
Kyle Moffett
--
If you don't believe that a case based on [nothing] could potentially
drag on in court for _years_, then you have no business playing with
the legal system at all.
-- Rob Landley
On Fri, Feb 10, 2006 at 01:35:33AM +0100, Pavel Machek wrote:
> > On Fri, Feb 10, 2006 at 12:35:04AM +0100, Rafael J. Wysocki wrote:
> > > Now, the question is do we chroot or not?
> >
> > What's wrong with setrlimit(RLIMIT_NOFILE, 0) (and RLIMIT_CORE). So
> > long as you open all your necessary device nodes before doing so.
>
> Nothing, but we got chroot idea, first.
Kinda like suspend2 didn't get into the kernel first?
I still think you're reinventing the wheel, and making it triangular :(
I don't understand your motivations for moving something that is so
intimately tied to the running kernel itself into userspace. A mouse
driver, sure. But the more I think about it, the more it seems nuts to me.
Bernard.
--
Bernard Blackham <bernard at blackham dot com dot au>
Hi,
On Saturday 11 February 2006 09:55, Bernard Blackham wrote:
> On Fri, Feb 10, 2006 at 01:35:33AM +0100, Pavel Machek wrote:
> > > On Fri, Feb 10, 2006 at 12:35:04AM +0100, Rafael J. Wysocki wrote:
> > > > Now, the question is do we chroot or not?
> > >
> > > What's wrong with setrlimit(RLIMIT_NOFILE, 0) (and RLIMIT_CORE). So
> > > long as you open all your necessary device nodes before doing so.
> >
> > Nothing, but we got chroot idea, first.
>
> Kinda like suspend2 didn't get into the kernel first?
Practically that's 4 lines of setrlimit() code vs 4 lines of chroot()/chdir()
code, so what's the problem? We can do this, we can do that, and we
can replace this with that at any time, so it really doesn't matter. Or
if you think it does, please let me know why.
> I still think you're reinventing the wheel, and making it triangular :(
To some extent you are right, but I don't agree with the "triangular"
part.
> I don't understand your motivations for moving something that is so
> intimately tied to the running kernel itself into userspace. A mouse
> driver, sure. But the more I think about it, the more it seems nuts to me.
Could you please provide some arguments? The more technical/practical they
are, the better.
It is possible you are right and we're just missing something important, so
let's discuss it. Seriously.
Greetings,
Rafael
On Sat, Feb 11, 2006 at 01:16:51AM +0100, Sebastian K?gler wrote:
> I, as a contributors to suspend2, have been working on all that stuff
> for about two-and-a-half years, and it makes me really sad to see that
> someone in a position to make a decision towards progress wants to
> start that whole process all over, rather than acknowledging the
> existance of a technical superior solution - including a
> well-functioning supporting community - and working towards getting
> this solution available for a wider audience.
I have to completly agree with Sebastian here. 16 months ago I was in
the need to have a suspend mode running on my new notebook. Back then
Suspend 2 was the only choice, and while it had still problems it was
surprisingly well behaving (in contrast to S3 mode and the mainline
swsusp). The support of the community was, as said above, very good, and
most issues very fixed fast.
Since it worked good for me, I started to contribute by supplying Fedora
patched kernels, helper packages and some documentation. Today on
Fedora, it is as easy as installing 4 RPM-packages and adding the
"resume2=" parameter to the kernel commandline, and I know that it works
this well on several other distributions too.
> Judging from experience, uswsusp is probably two years away until it
> can even come close to what suspend2 offers right now, and that would
> be the ideal case of having a lot of people helping in the progress,
> involving being actively involved and dedicated to fixing problems.
I think similar. Much effort was put into getting Suspend 2 to work
reliably and stable.
Some numbers: I have running Suspend 2 myself on three different systems
with total different hardware. For over half a year I have not have had
a single failure in suspending/resuming on any of the machines. With one
machine I had around 70 suspend/resume cycles without a reboot, working
with the machine for several hours a day, until I decided to update to a
newer kernel last week (and it is still running fine).
Some more numbers: judging from my access logs and the feedback I get, I
suspect at least 2000 Fedora users using Suspend 2 on a regular basis
with success. Listening to the IRC channel and reading the forums and
wikis, I see a huge bunch of people using Suspend 2 on nearly every
distribution. The problems are incredible low, mostly minor things that
get fixed nearly instantly.
Some pros of Suspend 2 from my view:
- it is reliable and stable (really!)
- it is fast (10-30 seconds on my notebook with 1280 MB ram, depending
on how much caches are saved)
- it can save all buffers and caches and the system is instantly
responsible after resume (even Windows cannot do this and is very slow
the first minute after resume)
- it works on all major platforms (x86, SMP, x86_64, there were success
reports for PPC, and I believe even ARM works)
- and the most important thing, as already said, it is available _today_
The only con I see is the complexity of the code, but then again, Nigel
did an incredible job in cleaning up. In the beginning (16 months ago) I
had a lot of trouble in applying the Suspend 2 patches to the Fedora
distribution kernel, but today (and for a long time now) the patches
nearly apply instantly.
From my point of view I see no such great advantage in having suspend in
userspace, but that does not mean it shouldn't be done. It might work
in some time, that is ok, but in the mean time I really would consider
in getting Suspend 2 mainline, because it works today, and I would agree
with Sebastian that it will take its time to get uswsusp running.
Again, you said the code is complex, it might be, but still most part of
the code is completly seperate from the rest of the kernel, and only
touches minor things (and Nigel is still working on that). I believe it
would not hurt.
In my opinion having Suspend 2 in mainline now would be a great thing,
as it would make suspend available for many more people today. In fact
swsusp and Suspend 2 can happily coexist for some time, giving people
the possibility to choose. After having both in mainline, efforts could
be put in developing uswsusp and maybe deprecating the other suspend
implementations one or two years later.
From a user, and contributor, point of view, I really do not understand
why not even trying to push a working implementation into mainline (I
know that you cannot just apply the Suspend 2 patches and shipping it,
but I know that Nigel will help there happily) but concentrate on things
which are just to begin, reinventing most of the wheel, and might take
some more years to get it work reliably.
Regards,
Matthias
Andrew Morton <[email protected]> writes:
> - If you want my cheerfully uninformed opinion, we should toss both of
> them out and implement suspend3, which is based on the kexec/kdump
> infrastructnure. There's so much duplication of intent here that it's not
> funny. And having them separate like this weakens both in the area where
> the real problems are: drivers.
Ahh!!! I'm surrounded.
suspend by kexec
suspend by migration
Is there a way out?
Can I avoid it?
Do all roads lead to suspend?
:)
Eric
On Sat, 11 Feb 2006 06:42:12 -0700 Eric W. Biederman wrote:
> Andrew Morton <[email protected]> writes:
>
> > - If you want my cheerfully uninformed opinion, we should toss both of
> > them out and implement suspend3, which is based on the kexec/kdump
> > infrastructnure. There's so much duplication of intent here that it's not
> > funny. And having them separate like this weakens both in the area where
> > the real problems are: drivers.
>
> Ahh!!! I'm surrounded.
>
> suspend by kexec
> suspend by migration
>
> Is there a way out?
>
> Can I avoid it?
>
> Do all roads lead to suspend?
>
> :)
All is not lost.
Recently I've had good results with suspend-to-disk (sort of a who cares).
And suspend-to-RAM seems to work for me.... but no resume. :(
---
~Randy
On Friday 10 February 2006 18:35, Pavel Machek wrote:
> Anyway, it means that suspend is still quite a hot topic, and that is
> good. (Linus said that suspend-to-disk is basically for people that
> can't get suspend-to-RAM to work, and after I got suspend-to-RAM to
> work reliably here, I can see his point).
I strongly disagree. I got suspend-to-RAM to work but its utility is seriously
limited by battery capacity. For example, on my laptop (Sony VGN-B100B) with
1.5GB of RAM, a fully charged battery is drained in about 18 hours if the
laptop was suspended to RAM.
Yes, for a few hours suspend-to-RAM is convenient but suspend-to-disk is
_reliable_ and _safe_.
Jan
Kyle Moffett wrote:
> On Feb 10, 2006, at 18:35, Pavel Machek wrote:
>
>> Anyway, it means that suspend is still quite a hot topic, and that is
>> good. (Linus said that suspend-to-disk is basically for people that
>> can't get suspend-to-RAM to work, and after I got suspend-to- RAM to
>> work reliably here, I can see his point).
>
>
> I completely agree. My Mac PowerBook has had suspend-to-RAM for a long
> time; I shut the lid and about 3 seconds later it's asleep, open it and
> 3 seconds later it's awake. Leave it sleeping for a week on a full
> charge, come back to find it still asleep. I can even put it to sleep,
> remove a drained battery and put in a fresh one (it has a small
> internal 2-minute RAM battery), then wake it up and resume work. I'm
> curious though, what proportion of laptop hardware actually has support
> for suspend-to-RAM? (including hardware for which linux does not yet
> have support).
I'd say about... 100% of all in use today :-) Really, I've not seen a
machine without APM or ACPI in ages...
> What percent of that hardware _does_ have Linux support?
85% I'd say. My notebook supports suspend, but not stand by, in Linux.
Suspend uses more battery. :-(
>
> Cheers,
> Kyle Moffett
>
> --
> If you don't believe that a case based on [nothing] could potentially
> drag on in court for _years_, then you have no business playing with
> the legal system at all.
> -- Rob Landley
>
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
--hackmiester
Walk a mile in my shoes and you will be a mile away in a new pair of shoes.
On Sat, 11 Feb 2006, Jan Merka wrote:
> On Friday 10 February 2006 18:35, Pavel Machek wrote:
>> Anyway, it means that suspend is still quite a hot topic, and that is
>> good. (Linus said that suspend-to-disk is basically for people that
>> can't get suspend-to-RAM to work, and after I got suspend-to-RAM to
>> work reliably here, I can see his point).
>
> I strongly disagree. I got suspend-to-RAM to work but its utility is seriously
> limited by battery capacity. For example, on my laptop (Sony VGN-B100B) with
> 1.5GB of RAM, a fully charged battery is drained in about 18 hours if the
> laptop was suspended to RAM.
>
> Yes, for a few hours suspend-to-RAM is convenient but suspend-to-disk is
> _reliable_ and _safe_.
People with dual-boot systems (before someone starts screaming, I know
people that dual-boot Linux as well for testing/development reasons) can
also benefit from STD. You just put Linux to sleep, boot your testing OS,
and when you are done just resume your normal Linux system and continue
working. Before I got a second PC, suspend (swsusp then) used to be a
savior for kernel driver testing...
On Feb 11, 2006, at 11:36, Jan Merka wrote:
> On Friday 10 February 2006 18:35, Pavel Machek wrote:
>> Anyway, it means that suspend is still quite a hot topic, and that
>> is good. (Linus said that suspend-to-disk is basically for people
>> that can't get suspend-to-RAM to work, and after I got suspend-to-
>> RAM to work reliably here, I can see his point).
>
> I strongly disagree. I got suspend-to-RAM to work but its utility
> is seriously limited by battery capacity. For example, on my laptop
> (Sony VGN-B100B) with 1.5GB of RAM, a fully charged battery is
> drained in about 18 hours if the laptop was suspended to RAM.
Ick, that's kind of sucky hardware then. My PowerBook with 1GB RAM
easily gets a week of sleep time off a fully charged battery; I don't
think I've rebooted it _once_ in the last 2 months, I just leave it
sleeping in my bag the whole time. Sony must be doing something
wrong, because there's easily enough power in a single battery to
keep RAM refreshed for a _long_ time.
> Yes, for a few hours suspend-to-RAM is convenient but suspend-to-
> disk is _reliable_ and _safe_.
As to the safety issue, I have my Apple Powerbook configured to
suspend to RAM, and if it gets critically low on battery I have the
firmware set to resume it automatically and my scripts shut it down
so I don't lose data. Suspend-to-RAM when implemented properly _is_
reliable and safe, but it seems like a lot of hardware manufacturers
get it wrong.
Cheers,
Kyle Moffett
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GCM/CS/IT/E/U d- s++: a18 C++++>$ ULBX*++++(+++)>$ P++++(+++)>$ L++++
(+++)>$ !E- W+++(++) N+++(++) o? K? w--- O? M++ V? PS+() PE+(-) Y+ PGP
+ t+(+++) 5 X R? !tv-(--) b++++(++) DI+(++) D+++ G e>++++$ h*(+)>++$ r
%(--) !y?-(--)
------END GEEK CODE BLOCK------
Kyle Moffett wrote:
> On Feb 11, 2006, at 11:36, Jan Merka wrote:
>> I strongly disagree. I got suspend-to-RAM to work but its utility is
>> seriously limited by battery capacity. For example, on my laptop (Sony
>> VGN-B100B) with 1.5GB of RAM, a fully charged battery is drained in
>> about 18 hours if the laptop was suspended to RAM.
>
> Ick, that's kind of sucky hardware then. My PowerBook with 1GB RAM
> easily gets a week of sleep time off a fully charged battery; I don't
> think I've rebooted it _once_ in the last 2 months, I just leave it
> sleeping in my bag the whole time. Sony must be doing something wrong,
> because there's easily enough power in a single battery to keep RAM
> refreshed for a _long_ time.
>
>> Yes, for a few hours suspend-to-RAM is convenient but suspend-to-disk
>> is _reliable_ and _safe_.
>
> As to the safety issue, I have my Apple Powerbook configured to suspend
> to RAM, and if it gets critically low on battery I have the firmware set
> to resume it automatically and my scripts shut it down so I don't lose
> data. Suspend-to-RAM when implemented properly _is_ reliable and safe,
> but it seems like a lot of hardware manufacturers get it wrong.
>
Hello,
I don't understand how a fundamental (good) debate of how
suspend to disk should be implemented in kernel, changed
into this one.
I don't care what Linus said... Suspend-to-disk is more
complicated than suspend-to-RAM. It is more complicated
since it provides more features. Suspend-to-RAM only stores
state, where Suspend-to-disk need to store the state
somewhere thus changing the initial state.
There is a long list of features available at
http://wiki.suspend2.net/FeatureUserRegister, which cannot
be provided using suspend-to-RAM, examples:
1. Store state on files - this allow you to resume your
machine into a different OS.
2. Encrypt state - this allow you to be sure that your data
is stored encrypted. (Yes... You can encrypt the memory...
but then you need a whole initramfs clone in order to allow
the user to specify how he want to encrypt/decrypt).
3. Network resume - this allow you to resume a network
machine (Not implemented yet, but cannot be done if
suspend-to-RAM is the sole implementation).
4. Support desktops/servers - this allow you to
suspend/resume hardware that is not designed to sleep, in
order to minimize downtime on power failure.
And another fact: Suspend-to-RAM implementation can be
derived form suspend-to-disk but not the other way around.
So let's invert the initial "fact"...
Suspend-to-RAM is basically for people that don't need the
full functionality of suspend-to-disk, after I got
suspend-to-disk to work reliably here (suspend2), I *NEVER*
use suspend-to-RAM.
Best Regards,
Alon Bar-Lev.
On Feb 12, 2006, at 03:51, Alon Bar-Lev wrote:
> 1. Store state on files
This is not a "feature", it's just something that causes a lot of
downsides (chew up disk space, fragment files, add code complexity,
etc).
> this allow you to resume your machine into a different OS.
This is the "feature". On the other hand, I'm going to argue that
this isn't really what we want to be doing for complexity reasons.
We want to implement the container and userspace-freeze code
described in the virtualization thread, then implement software-
suspend-and-resume-into-different-OS as freeze-userspace-container,
shutdown. Then you could trivially have different sets of working
data/processes, load up multiple sets at once, selectively freeze,
etc, with far less kernel complexity.
> 2. Encrypt state - this allow you to be sure that your data is
> stored encrypted. (Yes... You can encrypt the memory... but then
> you need a whole initramfs clone in order to allow the user to
> specify how he want to encrypt/decrypt).
Why the hell would you even _want_ to encrypt data in RAM? If you
have a secure OS install and a passworded screensaver that starts
before suspend, then there is _nothing_ an attacker could do to the
contents of RAM without hard-booting, which would just completely
erase it, or without extremely specialized hardware and expertise.
Picking up a machine suspended to RAM is just as secure as picking up
one that is on, no more or less.
> 3. Network resume - this allow you to resume a network machine (Not
> implemented yet, but cannot be done if
> suspend-to-RAM is the sole implementation).
>
> 4. Support desktops/servers - this allow you to suspend/resume
> hardware that is not designed to sleep, in order to minimize
> downtime on power failure.
This again is covered by the container-freeze stuff being implemented
as described above, and is unrelated to the suspend-to-RAM. When I
want suspend-to-RAM, I want something that will work instantly with
no overhead, so I can close my laptop and have it asleep 2 seconds
later, or open it and be able to use it within 2 seconds. That's an
extremely different use-case than the above two.
> And another fact: Suspend-to-RAM implementation can be derived form
> suspend-to-disk but not the other way around.
No, the two are _entirely_ independent. Suspend-to-RAM does not need
to copy memory at all, whereas suspend-to-disk requires it. That
very fact means that suspend-to-RAM is orders of magnitude faster
than suspend-to-disk could ever be, especially as RAM gets
exponentially larger.
> So let's invert the initial "fact"... Suspend-to-RAM is basically
> for people that don't need the full functionality of suspend-to-
> disk, after I got suspend-to-disk to work reliably here (suspend2),
> I *NEVER* use suspend-to-RAM.
No, suspend-to-ram is for people who need instant response times,
suspend-to-disk should be an extension or simplification of "Freeze a
process tree and all associated system status so we can completely
give up the hardware for a while". IMHO, the fact that both are
called "suspend" is just due to historical quirk as opposed to any
real similarity.
Cheers,
Kyle Moffett
--
There is no way to make Linux robust with unreliable memory
subsystems, sorry. It would be like trying to make a human more
robust with an unreliable O2 supply. Memory just has to work.
-- Andi Kleen
Kyle Moffett wrote:
> On Feb 12, 2006, at 03:51, Alon Bar-Lev wrote:
>> 2. Encrypt state - this allow you to be sure that your data is stored
>> encrypted. (Yes... You can encrypt the memory... but then you need a
>> whole initramfs clone in order to allow the user to specify how he
>> want to encrypt/decrypt).
>
> Why the hell would you even _want_ to encrypt data in RAM? If you have
> a secure OS install and a passworded screensaver that starts before
> suspend, then there is _nothing_ an attacker could do to the contents of
> RAM without hard-booting, which would just completely erase it, or
> without extremely specialized hardware and expertise. Picking up a
> machine suspended to RAM is just as secure as picking up one that is on,
> no more or less.
I guess you are not a security aware user...
A machine that is turned on is *MUCH* less secured than a
machine which is turned off and have its disks encrypted. We
can start argue on this issue too... But I won't cooperate...
>> And another fact: Suspend-to-RAM implementation can be derived form
>> suspend-to-disk but not the other way around.
>
> No, the two are _entirely_ independent. Suspend-to-RAM does not need to
> copy memory at all, whereas suspend-to-disk requires it. That very fact
> means that suspend-to-RAM is orders of magnitude faster than
> suspend-to-disk could ever be, especially as RAM gets exponentially larger.
Well... I see you already planned the implementation and
have all figured out...
But the fact is that suspend-to-RAM can be implemented by
suspend-to-disk without actually store the memory to
external device... But hay... You can implement and maintain
two separate solutions...
> No, suspend-to-ram is for people who need instant response times,
> suspend-to-disk should be an extension or simplification of "Freeze a
> process tree and all associated system status so we can completely give
> up the hardware for a while". IMHO, the fact that both are called
> "suspend" is just due to historical quirk as opposed to any real
> similarity.
Again... This is a matter of implementation... I believe
that one complete suspend implementation can suite both disk
and RAM... The only difference is if you write the state to
external storage, and how you play with APM. So there is a
good reason why both are called "suspend".
I don't claim that virtualization approach is not
appropriate, and in the future suspend may use this in order
to create its snapshot, and maybe, as you say, you may get
suspend-to-RAM in-kernel and suspend-to-disk in user-space
by dumping each process's container into a file (I don't
know what you do with graphics and caching... but let's
assume you have solution for all).
Let's see what happened so far:
First we had swsusp... For many people it did not work, so
Suspend2 was developed, but was not merged mainly because it
had too many UI components in-kernel.
Then comes the micro-kernel approach to convert swsusp into
uswsusp... Suspend2 which is stable now cannot be merged
since it violates this idea. So users will not get a proper
merged solution for at least one more year.
Now, you come with a different solution (virtualization), so
let's delay suspend feature for how long? At least two years?
We need (and can get) suspend to work *NOW*, laptops are
being more and more common... People expect to have this
ability in a modern operating system, they don't care if it
is implemented in kernel or in user-space, they also don't
care if you change it along the way... And if in the future
Linux will be pure virtual machine, all will be happy....
And use it... But please consider offering a working
solution *NOW*.
Best Regards,
Alon Bar-Lev.
On Feb 12, 2006, at 07:06, Alon Bar-Lev wrote:
> Kyle Moffett wrote:
>> Why the hell would you even _want_ to encrypt data in RAM? If you
>> have a secure OS install and a passworded screensaver that starts
>> before suspend, then there is _nothing_ an attacker could do to
>> the contents of RAM without hard-booting, which would just
>> completely erase it, or without extremely specialized hardware and
>> expertise. Picking up a machine suspended to RAM is just as
>> secure as picking up one that is on, no more or less.
>
> I guess you are not a security aware user... A machine that is
> turned on is *MUCH* less secured than a machine which is turned off
> and have its disks encrypted. We can start argue on this issue
> too... But I won't cooperate...
Where is your proof? This is quite true for a machine on a
_network_, but my suspended laptop isn't. You say that I am not a
security aware user and that therefore you are automatically right,
but it doesn't make it so. What is the practical vulnerability in my
laptop's suspend-to-ram, given that it automatically locks all VTs
and X when sleeping? Don't you *dare* say "somebody could attach a
hardware debugger and read your data out of RAM", because I just
don't see that happening in any reasonable situation, there are too
many obstacles to doing that with a _laptop_, the first of which is
just that it's impossible to take the damn thing apart when it's on
without disconnecting massive amounts of critical wiring. Even if
that _is_ a risk-case for you, it's not the use-case we should
optimize suspend for!
>>> And another fact: Suspend-to-RAM implementation can be derived
>>> form suspend-to-disk but not the other way around.
>>
>> No, the two are _entirely_ independent. Suspend-to-RAM does not
>> need to copy memory at all, whereas suspend-to-disk requires it.
>> That very fact means that suspend-to-RAM is orders of magnitude
>> faster than suspend-to-disk could ever be, especially as RAM gets
>> exponentially larger.
>
> Well... I see you already planned the implementation and have all
> figured out... But the fact is that suspend-to-RAM can be
> implemented by suspend-to-disk without actually store the memory to
> external device...
Right, the process goes something like this pseudocode:
put_devices_to_sleep(); /* [1] */
if (suspend_to_ram) {
call_firmware_suspend();
} else {
atomically_freeze_state();
wake_devices_up();
store_state_to_devices(); /* [2] */
put_devices_to_sleep();
switch(mode) {
SUSP_SHUTDOWN: shutdown();
SUSP_REBOOT: reboot();
[.......................]
}
}
Remind me again why we should implement suspend-to-RAM as part of
suspend-to-disk? Especially since the _only_ shared functionality is
[1] which is already separated out for other reasons. A lot of
people also seem to want to initiate and control all of [2] in
userspace, whereas the suspend-to-RAM case needs just one syscall.
> But hay... You can implement and maintain two separate solutions...
You still have yet to prove that suspend-to-RAM and suspend-to-disk
have anything to gain by being wrapped in a big if statement.
>> No, suspend-to-ram is for people who need instant response times,
>> suspend-to-disk should be an extension or simplification of
>> "Freeze a process tree and all associated system status so we can
>> completely give up the hardware for a while". IMHO, the fact that
>> both are called "suspend" is just due to historical quirk as
>> opposed to any real similarity.
>
> Again... This is a matter of implementation... I believe that one
> complete suspend implementation can suite both disk and RAM... The
> only difference is if you write the state to external storage, and
> how you play with APM. So there is a good reason why both are
> called "suspend".
>
> I don't claim that virtualization approach is not appropriate, and
> in the future suspend may use this in order to create its snapshot,
> and maybe, as you say, you may get suspend-to-RAM in-kernel and
> suspend-to-disk in user-space by dumping each process's container
> into a file (I don't know what you do with graphics and caching...
> but let's assume you have solution for all).
>
> Let's see what happened so far:
>
> First we had swsusp... For many people it did not work, so Suspend2
> was developed, but was not merged mainly because it had too many UI
> components in-kernel.
Actually, I seem to recall that even before _either_ of those were
working decently a bunch of modern hardware had good suspend-to-RAM
support.
> Then comes the micro-kernel approach to convert swsusp into
> uswsusp... Suspend2 which is stable now cannot be merged since it
> violates this idea. So users will not get a proper merged solution
> for at least one more year.
>
> Now, you come with a different solution (virtualization), so let's
> delay suspend feature for how long? At least two years?
Personally, I really don't care if you (or whoever) wants to merge an
intermediate suspend-to-disk/software-suspend implementation. I
think it would be helpful on a lot of laptops where suspend-to-RAM
doesn't work or chews battery. But I _really_ don't want to see
somebody trying to patch suspend-to-RAM/hardware-suspend into that mess.
> We need (and can get) suspend to work *NOW*,
It does work now, suspend-to-RAM/hardware-suspend has been working
perfectly on my laptop for a long time (modulo a couple powerbook USB
bugs that crept in recently and got removed). IMHO, a modern laptop
that doesn't support suspend-to-RAM is a broken design, although I
realize that it happens all too often.
> laptops are being more and more common... People expect to have
> this ability in a modern operating system, they don't care if it is
> implemented in kernel or in user-space, they also don't care if you
> change it along the way... And if in the future Linux will be pure
> virtual machine, all will be happy.... And use it... But please
> consider offering a working solution *NOW*.
On this I do agree, but _please_ don't muck with my suspend-to-RAM
along the way because of some egotistical "We are new-fancy-kernel-
software-suspend, resistance is futile" type thing, ok? Suspend-to-
RAM/hardware-suspend and suspend-to-disk/software-suspend are two
_completely_ different things and should not be treated the same at all.
Cheers,
Kyle Moffett
--
Premature optimization is the root of all evil in programming
-- C.A.R. Hoare
On Sunday 12 February 2006 02:51, Alon Bar-Lev wrote:
>
> Hello,
>
> I don't understand how a fundamental (good) debate of how
> suspend to disk should be implemented in kernel, changed
> into this one.
>
> I don't care what Linus said... Suspend-to-disk is more
> complicated than suspend-to-RAM. It is more complicated
And more useful in many cases... I'd just like to throw in here that when my
battery has seven minutes left and I have a month's uptime... I suspend to
disk. I also presume that many people do this as well.
> since it provides more features. Suspend-to-RAM only stores
> state, where Suspend-to-disk need to store the state
> somewhere thus changing the initial state.
>
> There is a long list of features available at
> http://wiki.suspend2.net/FeatureUserRegister, which cannot
> be provided using suspend-to-RAM, examples:
> 1. Store state on files - this allow you to resume your
> machine into a different OS.
> 2. Encrypt state - this allow you to be sure that your data
> is stored encrypted. (Yes... You can encrypt the memory...
> but then you need a whole initramfs clone in order to allow
> the user to specify how he want to encrypt/decrypt).
> 3. Network resume - this allow you to resume a network
> machine (Not implemented yet, but cannot be done if
> suspend-to-RAM is the sole implementation).
> 4. Support desktops/servers - this allow you to
> suspend/resume hardware that is not designed to sleep, in
> order to minimize downtime on power failure.
>
> And another fact: Suspend-to-RAM implementation can be
> derived form suspend-to-disk but not the other way around.
>
> So let's invert the initial "fact"...
> Suspend-to-RAM is basically for people that don't need the
> full functionality of suspend-to-disk, after I got
> suspend-to-disk to work reliably here (suspend2), I *NEVER*
> use suspend-to-RAM.
>
> Best Regards,
> Alon Bar-Lev.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
--hackmiester
If you can read this, you don't need glasses.
On Sun, 12 Feb 2006 11:32:44 EST, Kyle Moffett said:
> and X when sleeping? Don't you *dare* say "somebody could attach a
> hardware debugger and read your data out of RAM", because I just
> don't see that happening in any reasonable situation, there are too
> many obstacles to doing that with a _laptop_, the first of which is
> just that it's impossible to take the damn thing apart when it's on
> without disconnecting massive amounts of critical wiring.
No need to take anything apart if that laptop has a FireWire port on the
outside. See Quinn's Firestarter that won best hack at MacHack 2002.
http://www.quinn.echidna.id.au/Quinn/WWW/Hacks.html#FireStarter
No need to crack the case at all. And it isn't a Mac-only issue - it's the
way FireWire works.
On Feb 12, 2006, at 11:56, [email protected] wrote:
> On Sun, 12 Feb 2006 11:32:44 EST, Kyle Moffett said:
>> and X when sleeping? Don't you *dare* say "somebody could attach
>> a hardware debugger and read your data out of RAM", because I just
>> don't see that happening in any reasonable situation, there are
>> too many obstacles to doing that with a _laptop_, the first of
>> which is just that it's impossible to take the damn thing apart
>> when it's on without disconnecting massive amounts of critical
>> wiring.
>
> No need to take anything apart if that laptop has a FireWire port
> on the outside. See Quinn's Firestarter that won best hack at
> MacHack 2002.
>
> http://www.quinn.echidna.id.au/Quinn/WWW/Hacks.html#FireStarter
>
> No need to crack the case at all. And it isn't a Mac-only issue -
> it's the way FireWire works.
/me reads spec. *sigh* Whatever idiocy-committee wrote that spec was
clearly either smoking crack or living in a fantasy-world (or both).
An arbitrary unrestricted DMA bus is a massive and painfully obvious
security hole. Can somebody _please_ shoot the guy that came up with
that brilliant idea? At least it looks like it's not available if
the firewire modules aren't loaded, which means that you can prevent
that sort of attack, and my laptop luckily doesn't load those modules
at boot just to save a bit of memory. Even still, that's just a
terrible idea. Is there any practical way to restrict DMA and make
FireWire secure?
Cheers,
Kyle Moffett
--
I didn't say it would work as a defense, just that they can spin that
out for years in court if it came to it.
-- Rob Landley
On Sun, 2006-02-12 at 11:32 -0500, Kyle Moffett wrote:
> Don't you *dare* say "somebody could attach a
> hardware debugger and read your data out of RAM", because I just
> don't see that happening in any reasonable situation,
takes me all of about two minutes with your firewire port.
johannes
On Sun, 2006-02-12 at 13:28 -0500, Kyle Moffett wrote:
> /me reads spec. *sigh* Whatever idiocy-committee wrote that spec was
> clearly either smoking crack or living in a fantasy-world (or both).
> An arbitrary unrestricted DMA bus is a massive and painfully obvious
> security hole. Can somebody _please_ shoot the guy that came up with
> that brilliant idea? At least it looks like it's not available if
> the firewire modules aren't loaded, which means that you can prevent
> that sort of attack, and my laptop luckily doesn't load those modules
> at boot just to save a bit of memory.
might not help since your firmware turns on the firewire port to enable
booting from firewire disks.
> Even still, that's just a
> terrible idea. Is there any practical way to restrict DMA and make
> FireWire secure?
load the modules with phys_dma=0
johannes
Hi!
> >> And another fact: Suspend-to-RAM implementation can be derived form
> >> suspend-to-disk but not the other way around.
> >
> > No, the two are _entirely_ independent. Suspend-to-RAM does not need to
> > copy memory at all, whereas suspend-to-disk requires it. That very fact
> > means that suspend-to-RAM is orders of magnitude faster than
> > suspend-to-disk could ever be, especially as RAM gets exponentially larger.
>
> Well... I see you already planned the implementation and
> have all figured out...
> But the fact is that suspend-to-RAM can be implemented by
> suspend-to-disk without actually store the memory to
> external device...
No, it can not. See Doc*/power/video.txt . And there are more such problems.
> Again... This is a matter of implementation... I believe
> that one complete suspend implementation can suite both disk
> and RAM... The only difference is if you write the state to
> external storage, and how you play with APM. So there is a
How you play with ACPI/hw is major issue. Look at code to learn what you are talking
about. (and nobody uses APM today).
> Let's see what happened so far:
>
> First we had swsusp... For many people it did not work, so
...no; for many people it was too slow and not nice enough...
> Suspend2 was developed, but was not merged mainly because it
> had too many UI components in-kernel.
...and because Nigel did not care about mainline for a *long* time.
> Now, you come with a different solution (virtualization), so
> let's delay suspend feature for how long? At least two years?
Virtualization is separate topic. It could be used for s-t-disk,
but it is quite heavy solution, and not likely to be usable for s-t-disk for
4+ years.
> We need (and can get) suspend to work *NOW*, laptops are
> being more and more common... People expect to have this
> ability in a modern operating system, they don't care if it
> is implemented in kernel or in user-space, they also don't
> care if you change it along the way... And if in the future
> Linux will be pure virtual machine, all will be happy....
> And use it... But please consider offering a working
> solution *NOW*.
We have working solution *NOW*. It is called swsusp. If it does not work for you,
report it using bugzilla.kernel.org.
If you want something nicer/faster, help with suspend.sf.net.
Pavel
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
Hi!
> >Anyway, it means that suspend is still quite a hot topic, and that
> >is good. (Linus said that suspend-to-disk is basically for people
> >that can't get suspend-to-RAM to work, and after I got suspend-to-
> >RAM to work reliably here, I can see his point).
>
> I completely agree. My Mac PowerBook has had suspend-to-RAM for a
> long time; I shut the lid and about 3 seconds later it's asleep, open
> it and 3 seconds later it's awake. Leave it sleeping for a week on a
> full charge, come back to find it still asleep. I can even put it to
> sleep, remove a drained battery and put in a fresh one (it has a
> small internal 2-minute RAM battery), then wake it up and resume
> work. I'm curious though, what proportion of laptop hardware
> actually has support for suspend-to-RAM? (including hardware for
> which linux does not yet have support). What percent of that
> hardware _does_ have Linux support?
99%+ of notebooks can do s-t-ram, and perhaps 50% desktops.
Linux should work on 70% or so...
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
Hi!
Thanks for a fresh air in this flamewar...
> I have to completly agree with Sebastian here. 16 months ago I was in
> the need to have a suspend mode running on my new notebook. Back then
> Suspend 2 was the only choice, and while it had still problems it was
> surprisingly well behaving (in contrast to S3 mode and the mainline
> swsusp). The support of the community was, as said above, very good, and
> most issues very fixed fast.
Can you test recent swsusp?
>
> Since it worked good for me, I started to contribute by supplying Fedora
> patched kernels, helper packages and some documentation. Today on
> Fedora, it is as easy as installing 4 RPM-packages and adding the
> "resume2=" parameter to the kernel commandline, and I know that it works
> this well on several other distributions too.
...well, thanks for your good work.
> Some more numbers: judging from my access logs and the feedback I get, I
> suspect at least 2000 Fedora users using Suspend 2 on a regular basis
> with success. Listening to the IRC channel and reading the forums and
> wikis, I see a huge bunch of people using Suspend 2 on nearly every
> distribution. The problems are incredible low, mostly minor things that
> get fixed nearly instantly.
Well, at least Fedora and SuSE ship swsusp by default. So it is getting
huge ammount of testing, too.
>
> Some pros of Suspend 2 from my view:
> - it is reliable and stable (really!)
> - it is fast (10-30 seconds on my notebook with 1280 MB ram, depending
> on how much caches are saved)
> - it can save all buffers and caches and the system is instantly
> responsible after resume (even Windows cannot do this and is very slow
> the first minute after resume)
> - it works on all major platforms (x86, SMP, x86_64, there were success
> reports for PPC, and I believe even ARM works)
> - and the most important thing, as already said, it is available _today_
swsusp is also available today, and works better than you think. It is slightly
slower, but has all the other
features you listed in 2.6.16-rc3.
> The only con I see is the complexity of the code, but then again, Nigel
..but thats a big con.
> Again, you said the code is complex, it might be, but still most part of
> the code is completly seperate from the rest of the kernel, and only
> touches minor things (and Nigel is still working on that). I believe it
> would not hurt.
It would hurt at least me, Andrew and Linus... It would make lot
of suspend2 users very happy...
> From a user, and contributor, point of view, I really do not understand
> why not even trying to push a working implementation into mainline (I
> know that you cannot just apply the Suspend 2 patches and shipping it,
It is less work to port suspend2's features into userspace than to make
suspend2 acceptable to mainline. Both will mean big changes, and may
cause some short-term problems, but it will be less pain than
maintaining suspend2 forever. Please help with the former...
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
Hi.
On Sunday 19 February 2006 00:26, Pavel Machek wrote:
> Hi!
>
> Thanks for a fresh air in this flamewar...
>
> > I have to completly agree with Sebastian here. 16 months ago I was in
> > the need to have a suspend mode running on my new notebook. Back then
> > Suspend 2 was the only choice, and while it had still problems it was
> > surprisingly well behaving (in contrast to S3 mode and the mainline
> > swsusp). The support of the community was, as said above, very good, and
> > most issues very fixed fast.
>
> Can you test recent swsusp?
>
> > Since it worked good for me, I started to contribute by supplying Fedora
> > patched kernels, helper packages and some documentation. Today on
> > Fedora, it is as easy as installing 4 RPM-packages and adding the
> > "resume2=" parameter to the kernel commandline, and I know that it works
> > this well on several other distributions too.
>
> ...well, thanks for your good work.
>
> > Some more numbers: judging from my access logs and the feedback I get, I
> > suspect at least 2000 Fedora users using Suspend 2 on a regular basis
> > with success. Listening to the IRC channel and reading the forums and
> > wikis, I see a huge bunch of people using Suspend 2 on nearly every
> > distribution. The problems are incredible low, mostly minor things that
> > get fixed nearly instantly.
>
> Well, at least Fedora and SuSE ship swsusp by default. So it is getting
> huge ammount of testing, too.
>
> > Some pros of Suspend 2 from my view:
> > - it is reliable and stable (really!)
> > - it is fast (10-30 seconds on my notebook with 1280 MB ram, depending
> > on how much caches are saved)
> > - it can save all buffers and caches and the system is instantly
> > responsible after resume (even Windows cannot do this and is very slow
> > the first minute after resume)
> > - it works on all major platforms (x86, SMP, x86_64, there were success
> > reports for PPC, and I believe even ARM works)
> > - and the most important thing, as already said, it is available _today_
>
> swsusp is also available today, and works better than you think. It is
> slightly slower, but has all the other
> features you listed in 2.6.16-rc3.
It is a lot slower because it does all it's I/O synchronously, doesn't
compress the image and throws away memory until at least half is free.
> > The only con I see is the complexity of the code, but then again, Nigel
>
> ..but thats a big con.
It's fud. Hopefully as I post more suspend2 patches to LKML, people will see
that Suspend2 is simpler than what you are planning.
> > Again, you said the code is complex, it might be, but still most part of
> > the code is completly seperate from the rest of the kernel, and only
> > touches minor things (and Nigel is still working on that). I believe it
> > would not hurt.
>
> It would hurt at least me, Andrew and Linus... It would make lot
> of suspend2 users very happy...
Pavel, you're very good at making general hand waving statements, but terrible
at backing them up with facts, specifics or technical arguments. Could you
please do some more of the later?
> > From a user, and contributor, point of view, I really do not understand
> > why not even trying to push a working implementation into mainline (I
> > know that you cannot just apply the Suspend 2 patches and shipping it,
>
> It is less work to port suspend2's features into userspace than to make
> suspend2 acceptable to mainline. Both will mean big changes, and may
> cause some short-term problems, but it will be less pain than
> maintaining suspend2 forever. Please help with the former...
That's not true. I've taken time to look at what would be involved in making
suspend2 match the changes you're doing, and I've decided it's just not worth
the effort.
Let's be clear. uswsusp is not really moving suspend-to-disk to userspace.
What it is doing is leaving everything but some code for writing the image in
kernel space, and implementing ioctls to give a userspace program the ability
to request that other processes be frozen, the snapshot prepared and so on.
Pages in the snapshot are copied to userspace, possibly compressed or
encrypted there in future, then fed back to kernel space so it can use the
swap routines to do the writing. Very little of substance is being done in
userspace. In short, all it's doing is adding the complexity of always
requiring a userspace program, an initrd/ramfs, kernel routines to (1) export
the snapshot to userspace (2) receive pages to be written, and (3) let
userspace initiate the real work. It adds the complexity you complain about,
but with no addition in functionality or usability.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi!
> > swsusp is also available today, and works better than you think. It is
> > slightly slower, but has all the other
> > features you listed in 2.6.16-rc3.
>
> It is a lot slower because it does all it's I/O synchronously, doesn't
> compress the image and throws away memory until at least half is
> free.
uswsusp does compress image (20% speedup, in recent CVS) and do
asynchronous I/O.
> > > The only con I see is the complexity of the code, but then again, Nigel
> >
> > ..but thats a big con.
>
> It's fud. Hopefully as I post more suspend2 patches to LKML, people will see
> that Suspend2 is simpler than what you are planning.
For what I'm planning, all the neccessary patches are already in -mm
tree. And they are *really* simple. If you can get suspend2 to 1000
lines of code (like Rafael did with uswsusp), we can have something to
talk about.
> > > From a user, and contributor, point of view, I really do not understand
> > > why not even trying to push a working implementation into mainline (I
> > > know that you cannot just apply the Suspend 2 patches and shipping it,
> >
> > It is less work to port suspend2's features into userspace than to make
> > suspend2 acceptable to mainline. Both will mean big changes, and may
> > cause some short-term problems, but it will be less pain than
> > maintaining suspend2 forever. Please help with the former...
>
> That's not true. I've taken time to look at what would be involved in making
> suspend2 match the changes you're doing, and I've decided it's just not worth
> the effort.
>
> Let's be clear. uswsusp is not really moving suspend-to-disk to userspace.
> What it is doing is leaving everything but some code for writing the image in
> kernel space, and implementing ioctls to give a userspace program the ability
> to request that other processes be frozen, the snapshot prepared and so on.
> Pages in the snapshot are copied to userspace, possibly compressed or
> encrypted there in future, then fed back to kernel space so it can use the
> swap routines to do the writing. Very little of substance is being done in
> userspace. In short, all it's doing is adding the complexity of
Maybe very little of substance is being done in userspace, but all the
uglyness can stay there. I no longer need LZF in kernel, special
netlink API for progress bar (progress bar naturally lives in
userland), no plugin infrastructure needed, etc.
If you can do suspend2 without putting stuff listed above into kernel,
and in acceptable ammount of code... we can see. But you should really
put suspend2 code into userspace, and be done with that. Feel free to
spam l-k a bit more, but using existing infrastructure in -mm is right
way to go, and it is easier, too.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi!
> > > The only con I see is the complexity of the code, but then again, Nigel
> >
> > ..but thats a big con.
>
> It's fud. Hopefully as I post more suspend2 patches to LKML, people will see
> that Suspend2 is simpler than what you are planning.
Well, good luck with that. But since you claimed I'm spreading FUD, I
think I'll have to go through your patch.
Ouch, it is 500KB, 19K lines. How can you claim it is not complex?!
Lets see what can be done in userspace from that big patch.
diff -ruN linux-2.6.15-1/arch/arm/kernel/signal.c build-2.6.15.1/arch/arm/kernel/signal.c
--- linux-2.6.15-1/arch/arm/kernel/signal.c 2006-01-03 15:08:24.000000000 +1000
+++ build-2.6.15.1/arch/arm/kernel/signal.c 2006-01-23 21:38:28.000000000 +1000
@@ -637,7 +637,7 @@
if (!user_mode(regs))
return 0;
- if (try_to_freeze())
+ if (try_todo_list())
goto no_signal;
if (current->ptrace & PT_SINGLESTEP)
Unrelated to suspend2; either push it or drop it. [There are more such
changes, even for architectures you do not support suspend on... or do
you support suspend on h8300?]
diff -ruN linux-2.6.15-1/arch/frv/kernel/signal.c build-2.6.15.1/arch/frv/kernel/signal.c
diff -ruN linux-2.6.15-1/arch/h8300/kernel/signal.c build-2.6.15.1/arch/h8300/kernel/signal.c
diff -ruN linux-2.6.15-1/arch/i386/kernel/io_apic.c build-2.6.15.1/arch/i386/kernel/io_apic.c
diff -ruN linux-2.6.15-1/arch/i386/kernel/signal.c build-2.6.15.1/arch/i386/kernel/signal.c
Same here.
diff -ruN linux-2.6.15-1/arch/arm/mm/init.c build-2.6.15.1/arch/arm/mm/init.c
Ok, so you support arm.
diff -ruN linux-2.6.15-1/arch/i386/kernel/time.c build-2.6.15.1/arch/i386/kernel/time.c
--- linux-2.6.15-1/arch/i386/kernel/time.c 2006-01-03 15:08:25.000000000 +1000
+++ build-2.6.15.1/arch/i386/kernel/time.c 2006-01-23 21:38:28.000000000 +1000
@@ -372,7 +372,8 @@
mod_timer(&sync_cmos_timer, jiffies + 1);
}
-static long clock_cmos_diff, sleep_start;
+static long clock_cmos_diff;
+static unsigned long sleep_start;
static struct timer_opts *last_timer;
static int timer_suspend(struct sys_device *dev, pm_message_t state)
@@ -380,9 +381,11 @@
/*
* Estimate time zone so that set_time can update the clock
*/
- clock_cmos_diff = -get_cmos_time();
+ long cmos_time = __get_cmos_time();
+
+ clock_cmos_diff = -cmos_time;
clock_cmos_diff += get_seconds();
- sleep_start = get_cmos_time();
+ sleep_start = cmos_time;
last_timer = cur_timer;
cur_timer = &timer_none;
if (last_timer->suspend)
@@ -395,14 +398,16 @@
unsigned long flags;
unsigned long sec;
unsigned long sleep_length;
+ unsigned long cmos_time;
#ifdef CONFIG_HPET_TIMER
if (is_hpet_enabled())
hpet_reenable();
#endif
+ cmos_time = get_cmos_time();
+ sec = cmos_time + clock_cmos_diff;
+ sleep_length = (cmos_time - sleep_start) * HZ;
setup_pit_timer();
- sec = get_cmos_time() + clock_cmos_diff;
- sleep_length = (get_cmos_time() - sleep_start) * HZ;
write_seqlock_irqsave(&xtime_lock, flags);
xtime.tv_sec = sec;
xtime.tv_nsec = 0;
What problem does it solve? Do you want it in mainline? Unrelated to
suspend2.
diff -ruN linux-2.6.15-1/arch/i386/mm/init.c build-2.6.15.1/arch/i386/mm/init.c
diff -ruN linux-2.6.15-1/arch/m32r/kernel/signal.c build-2.6.15.1/arch/m32r/kernel/signal.c
diff -ruN linux-2.6.15-1/arch/mips/kernel/irixsig.c build-2.6.15.1/arch/mips/kernel/irixsig.c
diff -ruN linux-2.6.15-1/arch/mips/kernel/signal32.c build-2.6.15.1/arch/mips/kernel/signal32.c
diff -ruN linux-2.6.15-1/arch/powerpc/kernel/signal_32.c build-2.6.15.1/arch/powerpc/kernel/signal_32.c
diff -ruN linux-2.6.15-1/arch/ppc/mm/init.c build-2.6.15.1/arch/ppc/mm/init.c
diff -ruN linux-2.6.15-1/arch/ppc/platforms/pmac_feature.c build-2.6.15.1/arch/ppc/platforms/pmac_feature.c
diff -ruN linux-2.6.15-1/arch/sh/kernel/signal.c build-2.6.15.1/arch/sh/kernel/signal.c
diff -ruN linux-2.6.15-1/arch/sh64/kernel/signal.c build-2.6.15.1/arch/sh64/kernel/signal.c
diff -ruN linux-2.6.15-1/arch/x86_64/kernel/asm-offsets.c build-2.6.15.1/arch/x86_64/kernel/asm-offsets.c
--- linux-2.6.15-1/arch/x86_64/kernel/asm-offsets.c 2006-01-03 15:08:25.000000000 +1000
+++ build-2.6.15.1/arch/x86_64/kernel/asm-offsets.c 2006-01-23 21:38:28.000000000 +1000
@@ -61,8 +61,10 @@
offsetof (struct rt_sigframe32, uc.uc_mcontext));
BLANK();
#endif
+#ifdef CONFIG_PM
DEFINE(pbe_address, offsetof(struct pbe, address));
DEFINE(pbe_orig_address, offsetof(struct pbe, orig_address));
DEFINE(pbe_next, offsetof(struct pbe, next));
+#endif
return 0;
}
Do we want this in mailine?
diff -ruN linux-2.6.15-1/arch/x86_64/kernel/e820.c build-2.6.15.1/arch/x86_64/kernel/e820.c
diff -ruN linux-2.6.15-1/arch/x86_64/kernel/signal.c build-2.6.15.1/arch/x86_64/kernel/signal.c
diff -ruN linux-2.6.15-1/arch/x86_64/kernel/suspend.c build-2.6.15.1/arch/x86_64/kernel/suspend.c
With uswsusp, you are using existing code...
--- linux-2.6.15-1/arch/x86_64/kernel/suspend.c 2006-01-03 15:08:25.000000000 +1000
+++ build-2.6.15.1/arch/x86_64/kernel/suspend.c 2006-01-23 21:38:28.000000000 +1000
@@ -141,7 +144,7 @@
}
-#ifdef CONFIG_SOFTWARE_SUSPEND
+#if defined(CONFIG_SOFTWARE_SUSPEND)
/* Defined in arch/x86_64/kernel/suspend_asm.S */
extern int restore_image(void);
@@ -220,4 +223,5 @@
restore_image();
return 0;
}
+
#endif /* CONFIG_SOFTWARE_SUSPEND */
Why such spurious changes?
diff -ruN linux-2.6.15-1/arch/x86_64/kernel/time.c build-2.6.15.1/arch/x86_64/kernel/time.c
--- linux-2.6.15-1/arch/x86_64/kernel/time.c 2006-01-03 15:08:25.000000000 +1000
+++ build-2.6.15.1/arch/x86_64/kernel/time.c 2006-01-23 21:38:28.000000000 +1000
@@ -509,11 +509,56 @@
return cycles_2_ns(a);
}
+unsigned long __get_cmos_time(void)
+{
+ unsigned int year, mon, day, hour, min, sec;
+
+ /*
+ * Do we need the spinlock in here too?
+ *
+ * If we're called directly (not via get_cmos_time),
+ * we're in the middle of a sysdev suspend/resume
+ * and interrupts are disabled, so this
+ * should be safe without any locking.
+ * -- NC
+ */
+
+ do {
+ sec = CMOS_READ(RTC_SECONDS);
+ min = CMOS_READ(RTC_MINUTES);
+ hour = CMOS_READ(RTC_HOURS);
+ day = CMOS_READ(RTC_DAY_OF_MONTH);
+ mon = CMOS_READ(RTC_MONTH);
+ year = CMOS_READ(RTC_YEAR);
+ } while (sec != CMOS_READ(RTC_SECONDS));
+
+ /*
+ * We know that x86-64 always uses BCD format, no need to check the config
+ * register.
+ */
+
+ BCD_TO_BIN(sec);
+ BCD_TO_BIN(min);
+ BCD_TO_BIN(hour);
+ BCD_TO_BIN(day);
+ BCD_TO_BIN(mon);
+ BCD_TO_BIN(year);
+
+ /*
+ * This will work up to Dec 31, 2069.
+ */
+
+ if ((year += 1900) < 1970)
+ year += 100;
+
+ return mktime(year, mon, day, hour, min, sec);
+}
+
unsigned long get_cmos_time(void)
{
- unsigned int timeout, year, mon, day, hour, min, sec;
+ unsigned int timeout;
unsigned char last, this;
- unsigned long flags;
+ unsigned long flags, result;
/*
* The Linux interpretation of the CMOS clock register contents: When the
@@ -534,39 +579,10 @@
timeout--;
}
-/*
- * Here we are safe to assume the registers won't change for a whole second, so
- * we just go ahead and read them.
- */
-
- sec = CMOS_READ(RTC_SECONDS);
- min = CMOS_READ(RTC_MINUTES);
- hour = CMOS_READ(RTC_HOURS);
- day = CMOS_READ(RTC_DAY_OF_MONTH);
- mon = CMOS_READ(RTC_MONTH);
- year = CMOS_READ(RTC_YEAR);
-
+ result = __get_cmos_time();
spin_unlock_irqrestore(&rtc_lock, flags);
-/*
- * We know that x86-64 always uses BCD format, no need to check the config
- * register.
- */
-
- BCD_TO_BIN(sec);
- BCD_TO_BIN(min);
- BCD_TO_BIN(hour);
- BCD_TO_BIN(day);
- BCD_TO_BIN(mon);
- BCD_TO_BIN(year);
-
-/*
- * x86-64 systems only exists since 2002.
- * This will work up to Dec 31, 2100
- */
- year += 2000;
-
- return mktime(year, mon, day, hour, min, sec);
+ return result;
}
#ifdef CONFIG_CPU_FREQ
@@ -1004,7 +1020,7 @@
/*
* Estimate time zone so that set_time can update the clock
*/
- long cmos_time = get_cmos_time();
+ long cmos_time = __get_cmos_time();
clock_cmos_diff = -cmos_time;
clock_cmos_diff += get_seconds();
What does this do? Seems independend from rest of suspend2.
diff -ruN linux-2.6.15-1/arch/x86_64/mm/init.c build-2.6.15.1/arch/x86_64/mm/init.c
diff -ruN linux-2.6.15-1/block/ll_rw_blk.c build-2.6.15.1/block/ll_rw_blk.c
diff -ruN linux-2.6.15-1/crypto/deflate.c build-2.6.15.1/crypto/deflate.c
--- linux-2.6.15-1/crypto/deflate.c 2006-01-03 15:08:25.000000000 +1000
+++ build-2.6.15.1/crypto/deflate.c 2006-01-23 21:38:28.000000000 +1000
@@ -143,8 +143,15 @@
ret = zlib_deflate(stream, Z_FINISH);
if (ret != Z_STREAM_END) {
- ret = -EINVAL;
- goto out;
+ if (!(ret == Z_OK && !stream->avail_in && !stream->avail_out)) {
+ ret = -EINVAL;
+ goto out;
+ } else {
+ u8 zerostuff = 0;
+ stream->next_out = &zerostuff;
+ stream->avail_out = 1;
+ ret = zlib_deflate(stream, Z_FINISH);
+ }
}
ret = 0;
*dlen = stream->total_out;
WTF is this?
diff -ruN linux-2.6.15-1/crypto/Kconfig build-2.6.15.1/crypto/Kconfig
--- linux-2.6.15-1/crypto/Kconfig 2006-01-03 15:08:25.000000000 +1000
+++ build-2.6.15.1/crypto/Kconfig 2006-01-23 21:38:28.000000000 +1000
@@ -285,6 +285,13 @@
You will most probably want this if using IPSec.
+config CRYPTO_LZF
+ tristate "LZF compression algorithm"
+ depends on CRYPTO
+ help
+ This is the LZF algorithm. It is especially useful for Suspend2,
+ because it achieves good compression quickly.
+
config CRYPTO_MICHAEL_MIC
tristate "Michael MIC keyed digest algorithm"
depends on CRYPTO
diff -ruN linux-2.6.15-1/crypto/lzf.c build-2.6.15.1/crypto/lzf.c
diff -ruN linux-2.6.15-1/crypto/Makefile build-2.6.15.1/crypto/Makefile
With uswsusp, LZF can stay in userspace.
diff -ruN linux-2.6.15-1/Documentation/kernel-parameters.txt build-2.6.15.1/Documentation/kernel-parameters.txt
--- linux-2.6.15-1/Documentation/kernel-parameters.txt 2006-01-03 15:08:24.000000000 +1000
+++ build-2.6.15.1/Documentation/kernel-parameters.txt 2006-01-23 21:38:28.000000000 +1000
@@ -71,6 +71,7 @@
SERIAL Serial support is enabled.
SMP The kernel is an SMP kernel.
SPARC Sparc architecture is enabled.
+ SUSPEND2 Suspend2 is enabled.
SWSUSP Software suspend is enabled.
TS Appropriate touchscreen support is enabled.
USB USB support is enabled.
@@ -966,6 +967,8 @@
noresume [SWSUSP] Disables resume and restores original swap
space.
+ noresume2 [SUSPEND2] Disables resuming and restores original swap signature.
+
no-scroll [VGA] Disables scrollback.
This is required for the Braillex ib80-piezo Braille
reader made by F.H. Papenmeier (Germany).
...and kernel parameters do not need to change...
diff -ruN linux-2.6.15-1/Documentation/power/internals.txt build-2.6.15.1/Documentation/power/internals.txt
--- linux-2.6.15-1/Documentation/power/internals.txt 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/Documentation/power/internals.txt 2006-01-23 21:38:28.000000000 +1000
+ Plugins are linked together in pipeline fashion. There may be zero or more
+ page transformers in a pipeline, and there is always exactly one writer.
+ The pipeline follows this pattern:
+
+ ---------------------------------
+ | Suspend2 Core
+ ---------------------------------
Notice missing '|'
+ |
+ |
+ ---------------------------------
+ | Page transformer 1 |
+ ---------------------------------
+ |
+ |
+ ---------------------------------
+ | Page transformer 2 |
+ ---------------------------------
+ |
+ |
+ ---------------------------------
+ | Writer |
+ ---------------------------------
Also notice that with uswsusp, this pipeline can stay in userspace.
diff -ruN linux-2.6.15-1/Documentation/power/kernel_threads.txt build-2.6.15.1/Documentation/power/kernel_threads.txt
diff -ruN linux-2.6.15-1/Documentation/power/suspend2.txt build-2.6.15.1/Documentation/power/suspend2.txt
...and extensive documentation can stay with userspace tools.
diff -ruN linux-2.6.15-1/Documentation/power/swsusp.txt build-2.6.15.1/Documentation/power/swsusp.txt
diff -ruN linux-2.6.15-1/drivers/acpi/osl.c build-2.6.15.1/drivers/acpi/osl.c
--- linux-2.6.15-1/drivers/acpi/osl.c 2006-01-03 15:08:26.000000000 +1000
+++ build-2.6.15.1/drivers/acpi/osl.c 2006-01-23 21:38:28.000000000 +1000
@@ -91,7 +91,7 @@
"Access to PCI configuration space unavailable\n");
return AE_NULL_ENTRY;
}
- kacpid_wq = create_singlethread_workqueue("kacpid");
+ kacpid_wq = create_nofreeze_singlethread_workqueue("kacpid");
BUG_ON(!kacpid_wq);
return AE_OK;
Big search and replace all over the tree. Changes the default to
unsafe one. Do you ever listen to comments?
diff -ruN linux-2.6.15-1/drivers/acpi/sleep/proc.c build-2.6.15.1/drivers/acpi/sleep/proc.c
diff -ruN linux-2.6.15-1/drivers/base/power/resume.c build-2.6.15.1/drivers/base/power/resume.c
--- linux-2.6.15-1/drivers/base/power/resume.c 2006-01-03 15:08:26.000000000 +1000
+++ build-2.6.15.1/drivers/base/power/resume.c 2006-01-23 21:38:28.000000000 +1000
@@ -101,6 +101,11 @@
list_del_init(entry);
list_add_tail(entry, &dpm_active);
resume_device(dev);
+ if (!irqs_disabled()) {
+ printk("WARNING: Interrupts reenabled while resuming sysdev driver %s.\n",
+ kobject_name(&dev->kobj));
+ local_irq_disable();
+ }
put_device(dev);
}
}
Nothing to do with suspend2. Either it is good idea or it is not, and
I think I saw mails telling you it is not.
diff -ruN linux-2.6.15-1/drivers/base/power/suspend.c build-2.6.15.1/drivers/base/power/suspend.c
diff -ruN linux-2.6.15-1/drivers/base/sys.c build-2.6.15.1/drivers/base/sys.c
...but you still keep the bad patches in your tree.
diff -ruN linux-2.6.15-1/drivers/block/pktcdvd.c build-2.6.15.1/drivers/block/pktcdvd.c
diff -ruN linux-2.6.15-1/drivers/char/agp/agp_suspend.h build-2.6.15.1/drivers/char/agp/agp_suspend.h
diff -ruN linux-2.6.15-1/drivers/char/agp/ati-agp.c build-2.6.15.1/drivers/char/agp/ati-agp.c
diff -ruN linux-2.6.15-1/drivers/char/agp/nvidia-agp.c build-2.6.15.1/drivers/char/agp/nvidia-agp.c
AGP stuff is independed with rest of code. Ahha, it was probably
included in latest trees, but your diff is still against 2.6.15.
diff -ruN linux-2.6.15-1/drivers/char/hvc_console.c build-2.6.15.1/drivers/char/hvc_console.c
diff -ruN linux-2.6.15-1/drivers/char/hvcs.c build-2.6.15.1/drivers/char/hvcs.c
diff -ruN linux-2.6.15-1/drivers/ieee1394/ieee1394_core.c build-2.6.15.1/drivers/ieee1394/ieee1394_core.c
diff -ruN linux-2.6.15-1/drivers/ieee1394/nodemgr.c build-2.6.15.1/drivers/ieee1394/nodemgr.c
diff -ruN linux-2.6.15-1/drivers/input/gameport/gameport.c build-2.6.15.1/drivers/input/gameport/gameport.c
diff -ruN linux-2.6.15-1/drivers/input/serio/serio.c build-2.6.15.1/drivers/input/serio/serio.c
--- linux-2.6.15-1/drivers/input/serio/serio.c 2006-01-03 15:08:26.000000000 +1000
+++ build-2.6.15.1/drivers/input/serio/serio.c 2006-01-23 21:38:28.000000000 +1000
@@ -314,6 +314,12 @@
serio_remove_duplicate_events(event);
serio_free_event(event);
+
+ if (unlikely(todo_list_active())) {
+ up(&serio_sem);
+ try_todo_list();
+ down(&serio_sem);
+ }
}
up(&serio_sem);
What is this?
diff -ruN linux-2.6.15-1/drivers/macintosh/Kconfig build-2.6.15.1/drivers/macintosh/Kconfig
--- linux-2.6.15-1/drivers/macintosh/Kconfig 2006-01-03 15:08:26.000000000 +1000
+++ build-2.6.15.1/drivers/macintosh/Kconfig 2006-01-23 21:38:28.000000000 +1000
@@ -192,4 +192,8 @@
tristate "Support for ANS LCD display"
depends on ADB_CUDA && PPC_PMAC
+config SOFTWARE_REPLACE_SLEEP
+ bool "Using Software suspend replace broken sleep function"
+ depends on SUSPEND2
+
endmenu
If sleep function is broken, why would you ever want it enabled? Why
does this need to be configurable?
diff -ruN linux-2.6.15-1/drivers/macintosh/therm_adt746x.c build-2.6.15.1/drivers/macintosh/therm_adt746x.c
diff -ruN linux-2.6.15-1/drivers/macintosh/via-pmu.c build-2.6.15.1/drivers/macintosh/via-pmu.c
diff -ruN linux-2.6.15-1/drivers/md/dm-crypt.c build-2.6.15.1/drivers/md/dm-crypt.c
diff -ruN linux-2.6.15-1/drivers/md/md.c build-2.6.15.1/drivers/md/md.c
diff -ruN linux-2.6.15-1/drivers/media/dvb/dvb-core/dvb_frontend.c build-2.6.15.1/drivers/media/dvb/dvb-core/dvb_frontend.c
diff -ruN linux-2.6.15-1/drivers/media/video/msp3400.c build-2.6.15.1/drivers/media/video/msp3400.c
diff -ruN linux-2.6.15-1/drivers/media/video/tvaudio.c build-2.6.15.1/drivers/media/video/tvaudio.c
diff -ruN linux-2.6.15-1/drivers/media/video/video-buf-dvb.c build-2.6.15.1/drivers/media/video/video-buf-dvb.c
diff -ruN linux-2.6.15-1/drivers/net/8139too.c build-2.6.15.1/drivers/net/8139too.c
diff -ruN linux-2.6.15-1/drivers/net/irda/sir_kthread.c build-2.6.15.1/drivers/net/irda/sir_kthread.c
--- linux-2.6.15-1/drivers/net/irda/sir_kthread.c 2006-01-03 15:08:29.000000000 +1000
+++ build-2.6.15.1/drivers/net/irda/sir_kthread.c 2006-01-23 21:38:28.000000000 +1000
@@ -112,6 +112,7 @@
DECLARE_WAITQUEUE(wait, current);
daemonize("kIrDAd");
+ current->flags |= PF_NOFREEZE;
irda_rq_queue.thread = current;
@@ -134,9 +135,6 @@
__set_task_state(current, TASK_RUNNING);
remove_wait_queue(&irda_rq_queue.kick, &wait);
- /* make swsusp happy with our thread */
- try_to_freeze();
-
run_irda_queue();
}
Why do you need irda threads running during suspend?
diff -ruN linux-2.6.15-1/drivers/net/irda/stir4200.c build-2.6.15.1/drivers/net/irda/stir4200.c
diff -ruN linux-2.6.15-1/drivers/net/wireless/airo.c build-2.6.15.1/drivers/net/wireless/airo.c
diff -ruN linux-2.6.15-1/drivers/pcmcia/cs.c build-2.6.15.1/drivers/pcmcia/cs.c
diff -ruN linux-2.6.15-1/drivers/pnp/pnpbios/core.c build-2.6.15.1/drivers/pnp/pnpbios/core.c
diff -ruN linux-2.6.15-1/drivers/scsi/hosts.c build-2.6.15.1/drivers/scsi/hosts.c
diff -ruN linux-2.6.15-1/drivers/scsi/lpfc/lpfc_init.c build-2.6.15.1/drivers/scsi/lpfc/lpfc_init.c
diff -ruN linux-2.6.15-1/drivers/usb/core/hub.c build-2.6.15.1/drivers/usb/core/hub.c
diff -ruN linux-2.6.15-1/drivers/usb/gadget/file_storage.c build-2.6.15.1/drivers/usb/gadget/file_storage.c
diff -ruN linux-2.6.15-1/drivers/usb/net/pegasus.c build-2.6.15.1/drivers/usb/net/pegasus.c
diff -ruN linux-2.6.15-1/drivers/usb/storage/usb.c build-2.6.15.1/drivers/usb/storage/usb.c
diff -ruN linux-2.6.15-1/drivers/w1/w1.c build-2.6.15.1/drivers/w1/w1.c
diff -ruN linux-2.6.15-1/fs/afs/kafsasyncd.c build-2.6.15.1/fs/afs/kafsasyncd.c
diff -ruN linux-2.6.15-1/fs/afs/kafstimod.c build-2.6.15.1/fs/afs/kafstimod.c
diff -ruN linux-2.6.15-1/fs/jbd/journal.c build-2.6.15.1/fs/jbd/journal.c
diff -ruN linux-2.6.15-1/fs/jffs/intrep.c build-2.6.15.1/fs/jffs/intrep.c
diff -ruN linux-2.6.15-1/fs/jffs2/background.c build-2.6.15.1/fs/jffs2/background.c
diff -ruN linux-2.6.15-1/fs/jfs/jfs_logmgr.c build-2.6.15.1/fs/jfs/jfs_logmgr.c
diff -ruN linux-2.6.15-1/fs/jfs/jfs_txnmgr.c build-2.6.15.1/fs/jfs/jfs_txnmgr.c
diff -ruN linux-2.6.15-1/fs/lockd/clntlock.c build-2.6.15.1/fs/lockd/clntlock.c
diff -ruN linux-2.6.15-1/fs/lockd/clntproc.c build-2.6.15.1/fs/lockd/clntproc.c
diff -ruN linux-2.6.15-1/fs/lockd/svc.c build-2.6.15.1/fs/lockd/svc.c
diff -ruN linux-2.6.15-1/fs/xfs/linux-2.6/xfs_buf.c build-2.6.15.1/fs/xfs/linux-2.6/xfs_buf.c
diff -ruN linux-2.6.15-1/fs/xfs/linux-2.6/xfs_super.c build-2.6.15.1/fs/xfs/linux-2.6/xfs_super.c
So you run big search & replace all over the tree, making your diff
huge. Either drop them or merge them...
diff -ruN linux-2.6.15-1/include/asm-arm/hw_irq.h build-2.6.15.1/include/asm-arm/hw_irq.h
--- linux-2.6.15-1/include/asm-arm/hw_irq.h 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/include/asm-arm/hw_irq.h 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,4 @@
+#ifndef __ASM_HARDIRQ_H
+#define __ASM_HARDIRQ_H
+#include <asm/hardirq.h>
+#endif
What does this have to do with suspend2?
diff -ruN linux-2.6.15-1/include/asm-arm/suspend2.h build-2.6.15.1/include/asm-arm/suspend2.h
diff -ruN linux-2.6.15-1/include/asm-i386/mach-default/mach_time.h build-2.6.15.1/include/asm-i386/mach-default/mach_time.h
diff -ruN linux-2.6.15-1/include/asm-i386/suspend2.h build-2.6.15.1/include/asm-i386/suspend2.h
--- linux-2.6.15-1/include/asm-i386/suspend2.h 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/include/asm-i386/suspend2.h 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,288 @@
+ /*
+ * Copyright 2003-2005 Nigel Cunningham <[email protected]>
+ * Based on code
+ * Copyright 2001-2002 Pavel Machek <[email protected]>
+ * Based on code
+ * Copyright 2001 Patrick Mochel <[email protected]>
+ */
+#include <linux/irq.h>
+#include <asm/desc.h>
+#include <asm/i387.h>
+#include <asm/tlbflush.h>
+#include <asm/desc.h>
+#include <asm/processor.h>
+
+/* image of the saved processor states */
+struct suspend2_saved_context {
+ u32 eax, ebx, ecx, edx;
+ u32 esp, ebp, esi, edi;
+ u16 es, fs, gs, ss;
+ u32 cr0, cr2, cr3, cr4;
+ u16 gdt_pad;
+ u16 gdt_limit;
+ u32 gdt_base;
+ u16 idt_pad;
+ u16 idt_limit;
+ u32 idt_base;
+ u16 ldt;
+ u16 tss;
+ u32 tr;
+ u32 safety;
+ u32 return_address;
+ u32 eflags;
+} __attribute__((packed));
+typedef struct suspend2_saved_context suspend2_saved_context_t;
+
+/* temporary storage */
+extern struct suspend2_saved_context suspend2_saved_context;
+
+/*
+ * save_processor_context
+ *
+ * Save the state of the processor before we go to sleep.
+ *
+ * return_stack is the value of the stack pointer (%esp) as the caller sees it.
+ * A good way could not be found to obtain it from here (don't want to make
+ * _too_ many assumptions about the layout of the stack this far down.) Also,
+ * the handy little __builtin_frame_pointer(level) where level > 0, is blatantly
+ * buggy - it returns the value of the stack at the proper location, not the
+ * location, like it should (as of gcc 2.91.66)
+ *
+ * Note that the context and timing of this function is pretty critical.
+ * With a minimal amount of things going on in the caller and in here, gcc
+ * does a good job of being just a dumb compiler. Watch the assembly output
+ * if anything changes, though, and make sure everything is going in the right
+ * place.
+ */
+static inline void suspend2_arch_save_processor_context(void)
+{
+ kernel_fpu_begin();
+
+ /*
+ * descriptor tables
+ */
+ asm volatile ("sgdt (%0)" : "=m" (suspend2_saved_context.gdt_limit));
+ asm volatile ("sidt (%0)" : "=m" (suspend2_saved_context.idt_limit));
+ asm volatile ("sldt (%0)" : "=m" (suspend2_saved_context.ldt));
+ asm volatile ("str (%0)" : "=m" (suspend2_saved_context.tr));
+
+ /*
+ * save the general registers.
+ * note that gcc has constructs to specify output of certain registers,
+ * but they're not used here, because it assumes that you want to modify
+ * those registers, so it tries to be smart and save them beforehand.
+ * It's really not necessary, and kinda fishy (check the assembly output),
+ * so it's avoided.
+ */
+ asm volatile ("movl %%esp, (%0)" : "=m" (suspend2_saved_context.esp));
+ asm volatile ("movl %%eax, (%0)" : "=m" (suspend2_saved_context.eax));
+ asm volatile ("movl %%ebx, (%0)" : "=m" (suspend2_saved_context.ebx));
+ asm volatile ("movl %%ecx, (%0)" : "=m" (suspend2_saved_context.ecx));
+ asm volatile ("movl %%edx, (%0)" : "=m" (suspend2_saved_context.edx));
+ asm volatile ("movl %%ebp, (%0)" : "=m" (suspend2_saved_context.ebp));
+ asm volatile ("movl %%esi, (%0)" : "=m" (suspend2_saved_context.esi));
+ asm volatile ("movl %%edi, (%0)" : "=m" (suspend2_saved_context.edi));
+
+ /*
+ * segment registers
+ */
+ asm volatile ("movw %%es, %0" : "=r" (suspend2_saved_context.es));
+ asm volatile ("movw %%fs, %0" : "=r" (suspend2_saved_context.fs));
+ asm volatile ("movw %%gs, %0" : "=r" (suspend2_saved_context.gs));
+ asm volatile ("movw %%ss, %0" : "=r" (suspend2_saved_context.ss));
+
+ /*
+ * control registers
+ */
+ asm volatile ("movl %%cr0, %0" : "=r" (suspend2_saved_context.cr0));
+ asm volatile ("movl %%cr2, %0" : "=r" (suspend2_saved_context.cr2));
+ asm volatile ("movl %%cr3, %0" : "=r" (suspend2_saved_context.cr3));
+ asm volatile ("movl %%cr4, %0" : "=r" (suspend2_saved_context.cr4));
+
+ /*
+ * eflags
+ */
+ asm volatile ("pushfl ; popl (%0)" : "=m" (suspend2_saved_context.eflags));
+}
Can't you use existing suspend functions?
Same for the rest of file...
+static inline void suspend2_arch_flush_caches(void)
+{
+#ifdef CONFIG_SMP
+ cpu_clear(0, per_cpu(cpu_tlbstate,
+ 0).active_mm->cpu_vm_mask);
+#endif
+ wbinvd();
+ __flush_tlb_all();
+
+}
+
+static inline void suspend2_arch_post_copyback(void)
+{
+ BUG_ON(!irqs_disabled());
+
+ current_cpu_data.loops_per_jiffy =
+ c_loops_per_jiffy_ref;
+#ifndef CONFIG_SMP
+ loops_per_jiffy = c_loops_per_jiffy_ref;
+ cpu_khz = cpu_khz_ref;
+#endif
+}
+
+#endif
What is this? Is your method of dealing with SMP different from
mainline's?
diff -ruN linux-2.6.15-1/include/asm-ppc/cpu_context.h build-2.6.15.1/include/asm-ppc/cpu_context.h
diff -ruN linux-2.6.15-1/include/asm-x86_64/page.h build-2.6.15.1/include/asm-x86_64/page.h
diff -ruN linux-2.6.15-1/include/asm-x86_64/suspend2.h build-2.6.15.1/include/asm-x86_64/suspend2.h
Same here. You should be able to use mainline's snapshot
functionality. That's common piece between swsusp and suspend2, and
having your own copy helps noone.
diff -ruN linux-2.6.15-1/include/asm-x86_64/suspend.h build-2.6.15.1/include/asm-x86_64/suspend.h
diff -ruN linux-2.6.15-1/include/linux/bio.h build-2.6.15.1/include/linux/bio.h
--- linux-2.6.15-1/include/linux/bio.h 2006-01-03 15:08:44.000000000 +1000
+++ build-2.6.15.1/include/linux/bio.h 2006-01-23 21:38:28.000000000 +1000
@@ -124,6 +124,7 @@
#define BIO_BOUNCED 5 /* bio is a bounce bio */
#define BIO_USER_MAPPED 6 /* contains user pages */
#define BIO_EOPNOTSUPP 7 /* not supported */
+#define BIO_SUSPEND2 8 /* Suspend2 bio - for corruption checking */
#define bio_flagged(bio, flag) ((bio)->bi_flags & (1 << (flag)))
/*
You just should not corrupt the data...
diff -ruN linux-2.6.15-1/include/linux/dyn_pageflags.h build-2.6.15.1/include/linux/dyn_pageflags.h
--- linux-2.6.15-1/include/linux/dyn_pageflags.h 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/include/linux/dyn_pageflags.h 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,66 @@
+
+typedef unsigned long *** dyn_pageflags_t;
+
Eh....
Could not you just use normal page flags like swsusp does?
diff -ruN linux-2.6.15-1/include/linux/freezer.h build-2.6.15.1/include/linux/freezer.h
--- linux-2.6.15-1/include/linux/freezer.h 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/include/linux/freezer.h 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,28 @@
+/* Freezer declarations */
+
+#define FREEZER_ON 0
+#define ABORT_FREEZING 1
+
+#define FREEZER_KERNEL_THREADS 0
+#define FREEZER_ALL_THREADS 1
+
+#ifdef CONFIG_PM
+extern unsigned long freezer_state;
+
+#define test_freezer_state(bit) test_bit(bit, &freezer_state)
+#define set_freezer_state(bit) set_bit(bit, &freezer_state)
+#define clear_freezer_state(bit) clear_bit(bit, &freezer_state)
+
+#define freezer_is_on() (test_freezer_state(FREEZER_ON))
+
+extern void do_freeze_process(struct notifier_block *nl);
+
+#else
+
+#define test_freezer_state(bit) (0)
+#define set_freezer_state(bit) do { } while(0)
+#define clear_freezer_state(bit) do { } while(0)
+
+#define freezer_is_on() (0)
+
+#endif
So you have your own freezer. Can you still reproduce some failures in
mainline's freezer? There's one nasty case with vfork() we do not have
solved...
diff -ruN linux-2.6.15-1/include/linux/kernel.h build-2.6.15.1/include/linux/kernel.h
--- linux-2.6.15-1/include/linux/kernel.h 2006-01-03 15:08:45.000000000 +1000
+++ build-2.6.15.1/include/linux/kernel.h 2006-01-23 21:38:28.000000000 +1000
@@ -103,6 +103,8 @@
__attribute__ ((format (printf, 2, 0)));
extern int snprintf(char * buf, size_t size, const char * fmt, ...)
__attribute__ ((format (printf, 3, 4)));
+extern int snprintf_used(char *buffer, int buffer_size,
+ const char *fmt, ...);
extern int vsnprintf(char *buf, size_t size, const char *fmt, va_list args)
__attribute__ ((format (printf, 3, 0)));
extern int scnprintf(char * buf, size_t size, const char * fmt, ...)
Why do you need to modify printf-like functions?!
diff -ruN linux-2.6.15-1/include/linux/kthread.h build-2.6.15.1/include/linux/kthread.h
diff -ruN linux-2.6.15-1/include/linux/netlink.h build-2.6.15.1/include/linux/netlink.h
--- linux-2.6.15-1/include/linux/netlink.h 2006-01-03 15:08:45.000000000 +1000
+++ build-2.6.15.1/include/linux/netlink.h 2006-01-23 21:38:28.000000000 +1000
@@ -21,6 +21,8 @@
#define NETLINK_DNRTMSG 14 /* DECnet routing messages */
#define NETLINK_KOBJECT_UEVENT 15 /* Kernel messages to userspace */
#define NETLINK_GENERIC 16
+#define NETLINK_SUSPEND2_USERUI 17 /* For suspend2's userui */
+#define NETLINK_SUSPEND2_USM 18 /* For suspend2's userui */
#define MAX_LINKS 32
Yeh, and this is exactly why uswsusp is superior.
diff -ruN linux-2.6.15-1/include/linux/sched.h build-2.6.15.1/include/linux/sched.h
diff -ruN linux-2.6.15-1/include/linux/suspend2.h build-2.6.15.1/include/linux/suspend2.h
+
+/* Debug sections - if debugging compiled in */
+enum {
+ SUSPEND_ANY_SECTION,
+ SUSPEND_FREEZER,
+ SUSPEND_EAT_MEMORY,
+ SUSPEND_PAGESETS,
+ SUSPEND_IO,
+ SUSPEND_BMAP,
+ SUSPEND_HEADER,
+ SUSPEND_WRITER,
+ SUSPEND_MEMORY,
+ SUSPEND_EXTENTS,
+ SUSPEND_SPINLOCKS,
+ SUSPEND_MEM_POOL,
+ SUSPEND_RANGE_PARANOIA,
+ SUSPEND_NOSAVE,
+ SUSPEND_INTEGRITY
+};
+
+/* debugging levels. */
+#define SUSPEND_STATUS 0
+#define SUSPEND_ERROR 2
+#define SUSPEND_LOW 3
+#define SUSPEND_MEDIUM 4
+#define SUSPEND_HIGH 5
+#define SUSPEND_VERBOSE 6
+
+/* second status register */
+enum {
+ SUSPEND_REBOOT,
+ SUSPEND_PAUSE,
+ SUSPEND_SLOW,
+ SUSPEND_NOPAGESET2,
+ SUSPEND_LOGALL,
+ SUSPEND_CAN_CANCEL,
+ SUSPEND_KEEP_IMAGE,
+ SUSPEND_FREEZER_TEST,
+ SUSPEND_FREEZER_TEST_SHOWALL,
+ SUSPEND_SINGLESTEP,
+ SUSPEND_PAUSE_NEAR_PAGESET_END,
+ SUSPEND_USE_ACPI_S4,
+ SUSPEND_TEST_FILTER_SPEED,
+ SUSPEND_FREEZE_TIMERS,
+ SUSPEND_DISABLE_SYSDEV_SUPPORT,
+ SUSPEND_VGA_POST,
+ SUSPEND_TEST_BIO,
+ SUSPEND_NO_PAGESET2,
+};
+
Not sure what this does, but I surely don't like it.
+extern void __suspend_message(unsigned long section, unsigned long level, int log_normally,
+ const char *fmt, ...);
+
+#ifdef CONFIG_PM_DEBUG
+#define suspend_message(sn, lev, log, fmt, a...) \
+do { \
+ if (test_debug_state(sn)) \
+ __suspend_message(sn, lev, log, fmt, ##a); \
+} while(0)
+#else /* CONFIG_PM_DEBUG */
+#define suspend_message(sn, lev, log, fmt, a...) \
+do { \
+ if (lev == 0) \
+ __suspend_message(sn, lev, log, fmt, ##a); \
+} while(0)
+#endif /* CONFIG_PM_DEBUG */
+
+/* Suspend 2 */
Having your own debugging infrastructure means you are doing something
wrong.
+enum {
+ SUSPEND_DISABLED,
+ SUSPEND_RUNNING,
+ SUSPEND_RESUME_DEVICE_OK,
+ SUSPEND_NORESUME_SPECIFIED,
+ SUSPEND_COMMANDLINE_ERROR,
+ SUSPEND_IGNORE_IMAGE,
+ SUSPEND_SANITY_CHECK_PROMPT,
+ SUSPEND_FREEZER_ON,
+ SUSPEND_BLOCK_PAGE_ALLOCATIONS,
+ SUSPEND_USE_MEMORY_POOL,
+ SUSPEND_STAGE2_CONTINUE,
+ SUSPEND_FREEZE_SMP,
+ SUSPEND_PAGESET2_NOT_LOADED,
+ SUSPEND_CONTINUE_REQ,
+ SUSPEND_RESUMED_BEFORE,
+ SUSPEND_RUNNING_INITRD,
+ SUSPEND_RESUME_NOT_DONE,
+ SUSPEND_BOOT_TIME,
+ SUSPEND_NOW_RESUMING,
+ SUSPEND_SLAB_ALLOC_FALLBACK,
+ SUSPEND_IGNORE_LOGLEVEL,
+ SUSPEND_TIMER_FREEZER_ON,
+ SUSPEND_ACT_USED,
+ SUSPEND_DBG_USED,
+ SUSPEND_LVL_USED,
+ SUSPEND_TRYING_TO_RESUME,
+ SUSPEND_FORK_COPYBACK_THREAD,
+ SUSPEND_TRY_RESUME_RD,
+ SUSPEND_IGNORE_ROOTFS,
+};
What's this? DBG_USED? LVL_USED?
diff -ruN linux-2.6.15-1/include/linux/suspend.h build-2.6.15.1/include/linux/suspend.h
diff -ruN linux-2.6.15-1/include/linux/workqueue.h build-2.6.15.1/include/linux/workqueue.h
diff -ruN linux-2.6.15-1/init/do_mounts.c build-2.6.15.1/init/do_mounts.c
diff -ruN linux-2.6.15-1/init/do_mounts_initrd.c build-2.6.15.1/init/do_mounts_initrd.c
--- linux-2.6.15-1/init/do_mounts_initrd.c 2006-01-03 15:08:48.000000000 +1000
+++ build-2.6.15.1/init/do_mounts_initrd.c 2006-01-23 21:38:28.000000000 +1000
@@ -7,6 +7,7 @@
#include <linux/romfs_fs.h>
#include <linux/initrd.h>
#include <linux/sched.h>
+#include <linux/suspend.h>
#include "do_mounts.h"
@@ -58,10 +59,16 @@
pid = kernel_thread(do_linuxrc, "/linuxrc", SIGCHLD);
if (pid > 0) {
- while (pid != sys_wait4(-1, NULL, 0, NULL))
+ while (pid != sys_wait4(-1, NULL, 0, NULL)) {
yield();
+ try_to_freeze();
+ }
}
Not run_todo_list? Do we want this in mainline?
diff -ruN linux-2.6.15-1/init/main.c build-2.6.15.1/init/main.c
diff -ruN linux-2.6.15-1/kernel/audit.c build-2.6.15.1/kernel/audit.c
diff -ruN linux-2.6.15-1/kernel/fork.c build-2.6.15.1/kernel/fork.c
--- linux-2.6.15-1/kernel/fork.c 2006-01-03 15:08:48.000000000 +1000
+++ build-2.6.15.1/kernel/fork.c 2006-01-23 21:38:28.000000000 +1000
@@ -165,7 +166,13 @@
if (!tsk)
return NULL;
- ti = alloc_thread_info(tsk);
+ if (test_suspend_state(SUSPEND_FORK_COPYBACK_THREAD)) {
+ extern void * suspend2_get_nonconflicting_pages(int);
+ ti = suspend2_get_nonconflicting_pages(get_order(THREAD_SIZE));
+ printk("Starting a copyback thread %p\n", ti);
+ } else
+ ti = alloc_thread_info(tsk);
+
if (!ti) {
free_task_struct(tsk);
return NULL;
With code like this (in fork!) how can you claim it is not complex?
What does copyback do, anyway?
diff -ruN linux-2.6.15-1/kernel/kmod.c build-2.6.15.1/kernel/kmod.c
diff -ruN linux-2.6.15-1/kernel/kthread.c build-2.6.15.1/kernel/kthread.c
diff -ruN linux-2.6.15-1/kernel/power/atomic_copy.c build-2.6.15.1/kernel/power/atomic_copy.c
--- linux-2.6.15-1/kernel/power/atomic_copy.c 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/atomic_copy.c 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,473 @@
+/*
+ */
+
+#include <linux/suspend.h>
+#include <linux/highmem.h>
+#include <linux/kthread.h>
+#include <asm/setup.h>
+#include <asm/param.h>
+#include <asm/thread_info.h>
+#include "suspend2_common.h"
+#include "io.h"
+#include "power_off.h"
+#include "version.h"
+#include "ui.h"
+#include "plugins.h"
+#include "atomic_copy.h"
+#include "suspend2.h"
+#include "checksum.h"
+#include "pageflags.h"
+#include "debug_pagealloc.h"
+#include "storage.h"
+
+#include <asm/suspend2.h>
+
+volatile static int state1 __nosavedata = 0;
+volatile static int state2 __nosavedata = 0;
+volatile static int state3 __nosavedata = 0;
+volatile static int io_speed_save[2][2] __nosavedata;
+
Heh, nice... volatile probably means you got the locking wrong, and no
it is not nice to name variables like this.
Why can't you just use existing code for atomic copy?
(~400 lines of duplicated code skipped)
diff -ruN linux-2.6.15-1/kernel/power/atomic_copy.h build-2.6.15.1/kernel/power/atomic_copy.h
diff -ruN linux-2.6.15-1/kernel/power/block_io.h build-2.6.15.1/kernel/power/block_io.h
--- linux-2.6.15-1/kernel/power/block_io.h 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/block_io.h 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,76 @@
+/*
+ * block_io.h
+ *
+ * Copyright 2004-2005 Nigel Cunningham <[email protected]>
+ *
+ * Distributed under GPLv2.
+ *
+ * This file contains declarations for functions exported from
+ * block_io.c, which contains low level io functions.
+ */
+
+#include <linux/buffer_head.h>
+#include "extent.h"
+
+/*
+ * submit_params
+ *
+ * The structure we use for tracking submitted I/O.
+ */
+struct submit_params {
+ swp_entry_t swap_address;
+ struct page *page;
+ struct block_device *dev;
+ sector_t block[MAX_BUF_PER_PAGE];
+ int readahead_index;
+ struct submit_params *next;
+ int printme;
+};
+
+struct suspend2_bdev_info {
+ struct block_device *bdev;
+ dev_t dev_t;
+ int bmap_shift;
+ int blocks_per_page;
+};
+
+/*
+ * Our exported interface so the swapwriter and filewriter don't
+ * need these functions duplicated.
+ */
+struct suspend_bio_ops {
+ int (*submit_io) (int rw,
+ struct submit_params *submit_info, int syncio);
+ int (*bdev_page_io) (int rw, struct block_device *bdev, long pos,
+ struct page *page);
+ int (*rw_page) (int rw, struct page *page, int readahead_index,
+ int sync);
+ void (*wait_on_readahead) (int readahead_index);
+ void (*check_io_stats) (void);
+ void (*reset_io_stats) (void);
+ void (*finish_all_io) (void);
+ int (*prepare_readahead) (int index);
+ void (*cleanup_readahead) (int index);
+ struct page ** readahead_pages;
+ int (*readahead_ready) (int readahead_index);
+ int *need_extra_next;
+ int (*forward_one_page) (void);
+ void (*set_devinfo) (struct suspend2_bdev_info *info);
+ int (*read_init) (int stream_number);
+ int (*read_chunk) (struct page *buffer_page, int sync);
+ int (*read_cleanup) (void);
+ int (*write_init) (int stream_number);
+ int (*write_chunk) (struct page *buffer_page);
+ int (*write_cleanup) (void);
+ int (*read_header_chunk) (char *buffer, int buffer_size);
+ int (*write_header_chunk) (char *buffer, int buffer_size);
+ int (*write_header_chunk_finish) (void);
+};
So you have your own disk operations... Nothing like that is needed
with uswsusp.
diff -ruN linux-2.6.15-1/kernel/power/checksum.h build-2.6.15.1/kernel/power/checksum.h
--- linux-2.6.15-1/kernel/power/checksum.h 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/checksum.h 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,11 @@
+#ifdef CONFIG_SUSPEND2_CHECKSUMS
+extern void suspend2_verify_checksums(void);
+extern void suspend2_checksum_calculate_checksums(void);
+extern void suspend2_checksum_print_differences(void);
+extern int suspend2_allocate_checksum_pages(void);
+#else
+static inline void suspend2_verify_checksums(void) { };
+static inline void suspend2_checksum_calculate_checksums(void) { };
+static inline void suspend2_checksum_print_differences(void) { };
+static inline int suspend2_allocate_checksum_pages(void) { return 0; };
+#endif
...and checksums can happily live in userspace.
diff -ruN linux-2.6.15-1/kernel/power/compression.c build-2.6.15.1/kernel/power/compression.c
--- linux-2.6.15-1/kernel/power/compression.c 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/compression.c 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,638 @@
+/*
+ * kernel/power/suspend2_core/compression.c
Wrong filename.
+ * Copyright (C) 2003-2005 Nigel Cunningham <[email protected]>
+ *
+ * This file is released under the GPLv2.
+ *
+ * This file contains data compression routines for suspend,
+ * using LZH compression.
LZF?
Snipped 600 lines of code that can happily live in userspace.
diff -ruN linux-2.6.15-1/kernel/power/debug_pagealloc.c build-2.6.15.1/kernel/power/debug_pagealloc.c
--- linux-2.6.15-1/kernel/power/debug_pagealloc.c 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/debug_pagealloc.c 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,111 @@
+#include <linux/mm.h>
+#ifdef CONFIG_DEBUG_PAGEALLOC
+#include <linux/page-flags.h>
+#include <asm/pgtable.h>
+
+#include "pageflags.h"
+#include "suspend2.h"
+#include "pagedir.h"
What is this code doing?
diff -ruN linux-2.6.15-1/kernel/power/debug_pagealloc.h build-2.6.15.1/kernel/power/debug_pagealloc.h
diff -ruN linux-2.6.15-1/kernel/power/disk.c build-2.6.15.1/kernel/power/disk.c
diff -ruN linux-2.6.15-1/kernel/power/encryption.c build-2.6.15.1/kernel/power/encryption.c
--- linux-2.6.15-1/kernel/power/encryption.c 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/encryption.c 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,597 @@
+/*
+ * kernel/power/suspend2_core/encryption.c
+ *
+ * Copyright (C) 2003-2005 Nigel Cunningham <[email protected]>
+ *
+ * This file is released under the GPLv2.
+ *
+ * This file contains data encryption routines for suspend,
+ * using cryptoapi transforms.
+ *
+ * ToDo:
+ * - Apply min/max_keysize the cipher changes.
+ * - Test.
+ */
Snipped 550 lines of code that can happily live in userspace.
diff -ruN linux-2.6.15-1/kernel/power/extent.c build-2.6.15.1/kernel/power/extent.c
--- linux-2.6.15-1/kernel/power/extent.c 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/extent.c 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,247 @@
+/* kernel/power/suspend2_core/extent.c
+ *
+ * (C) 2003-2005 Nigel Cunningham <[email protected]>
+ *
+ * Distributed under GPLv2.
+ *
+ * These functions encapsulate the manipulation of storage metadata. For
+ * pageflags, we use dynamically allocated bitmaps.
+ */
+
I do not know why you want to use extents; existing code seems to work
well enough. Do you get .01% speedup or what?
diff -ruN linux-2.6.15-1/kernel/power/extent.h build-2.6.15.1/kernel/power/extent.h
+
+#define extent_state_eof(state) ((state)->num_chains < (state)->current_chain)
+
+#define extent_for_each(extent_chain, extentpointer, value) \
+if ((extent_chain)->first) \
+ for ((extentpointer) = (extent_chain)->first, (value) = \
+ (extentpointer)->minimum; \
+ ((extentpointer) && ((extentpointer)->next || (value) <= \
+ (extentpointer)->maximum)); \
+ (((value) == (extentpointer)->maximum) ? \
+ ((extentpointer) = (extentpointer)->next, (value) = \
+ ((extentpointer) ? (extentpointer)->minimum : 0)) : \
+ (value)++))
+
+/*
+ * When using compression and expected_compression > 0,
+ * we allocate fewer swap entries, so GET_EXTENT_NEXT can
+ * validly run out of data to return.
+ */
+#define GET_EXTENT_NEXT(currentextent, currentval) \
+{ \
+ if (currentextent) { \
+ if ((currentval) == (currentextent)->maximum) { \
+ if ((currentextent)->next) { \
+ (currentextent) = (currentextent)->next; \
+ (currentval) = (currentextent)->minimum; \
+ } else { \
+ (currentextent) = NULL; \
+ (currentval) = 0; \
+ } \
+ } else \
+ currentval++; \
+ } \
+}
Not nice at all.
diff -ruN linux-2.6.15-1/kernel/power/io.c build-2.6.15.1/kernel/power/io.c
--- linux-2.6.15-1/kernel/power/io.c 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/io.c 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,1025 @@
+/*
+ * kernel/power/io.c
+ *
+ * Copyright (C) 1998-2001 Gabor Kuti <[email protected]>
+ * Copyright (C) 1998,2001,2002 Pavel Machek <[email protected]>
+ * Copyright (C) 2002-2003 Florent Chabaud <[email protected]>
+ * Copyright (C) 2002-2005 Nigel Cunningham <[email protected]>
+ *
+ * This file is released under the GPLv2.
+ *
+ * It contains high level IO routines for suspending.
+ *
+ */
Snipped 1000 lines that can happily live in userspace. Yes, I have
similar (but way simpler) code in kernel just now. Notice I want to
remove it.
diff -ruN linux-2.6.15-1/kernel/power/io.h build-2.6.15.1/kernel/power/io.h
diff -ruN linux-2.6.15-1/kernel/power/Kconfig build-2.6.15.1/kernel/power/Kconfig
--- linux-2.6.15-1/kernel/power/Kconfig 2006-01-03 15:08:48.000000000 +1000
+++ build-2.6.15.1/kernel/power/Kconfig 2006-01-23 21:38:28.000000000 +1000
@@ -98,3 +98,76 @@
bool
depends on HOTPLUG_CPU && X86 && PM
default y
+
+config SUSPEND_DEBUG_PAGEALLOC
+ bool
+ depends on DEBUG_PAGEALLOC && (SOFTWARE_SUSPEND || SUSPEND2)
+ default y
+
+config SUSPEND2_CRYPTO
+ bool
+ depends on SUSPEND2 && CRYPTO
+ default y
+
+menuconfig SUSPEND2
+ bool "Suspend2"
+ select DYN_PAGEFLAGS
+ depends on PM
+ select HOTPLUG_CPU if SMP
+ ---help---
+ Suspend2 is the 'new and improved' suspend support.
+
+ See the Suspend2 home page (suspend2.net)
+ for FAQs, HOWTOs and other documentation.
+
+ comment 'Image Storage (you need at least one writer)'
+ depends on SUSPEND2
+
+ config SUSPEND2_FILEWRITER
+ bool ' File Writer'
+ depends on SUSPEND2
+ ---help---
+ This option enables support for storing an image in a
+ simple file. This should be possible, but we're still
+ testing it.
+
+ config SUSPEND2_SWAPWRITER
+ bool ' Swap Writer'
+ depends on SUSPEND2
+ select SWAP
+ ---help---
+ This option enables support for storing an image in your
+ swap space.
+
+ comment 'General Options'
+ depends on SUSPEND2
+
+ config SUSPEND2_DEFAULT_RESUME2
+ string ' Default resume device name'
+ depends on SUSPEND2
+ ---help---
+ You normally need to add a resume2= parameter to your lilo.conf or
+ equivalent. With this option properly set, the kernel has a value
+ to default. No damage will be done if the value is invalid.
+
+ config SUSPEND2_CHECKSUMMING
+ bool ' Checksum images - developer option (SLOW!)'
+ depends on PM_DEBUG && SUSPEND2
+ ---help---
+ This option implements checksumming of images. It is not designed
+ for everyone to use, but as a development tool.
+
+ config SUSPEND2_KEEP_IMAGE
+ bool ' Allow Keep Image Mode'
+ depends on SUSPEND2
+ ---help---
+ This option allows you to keep and image and reuse it. It is intended
+ __ONLY__ for use with systems where all filesystems are mounted read-
+ only (kiosks, for example). To use it, compile this option in and boot
+ normally. Set the KEEP_IMAGE flag in /proc/suspend2 and suspend.
+ When you resume, the image will not be removed. You will be unable to turn
+ off swap partitions (assuming you are using the swap writer), but future
+ suspends simply do a power-down. The image can be updated using the
+ kernel command line parameter suspend_act= to turn off the keep image
+ bit. Keep image mode is a little less user friendly on purpose - it
+ should not be used without thought!
All this configuration can and should be done in userspace. That's 70
lines.
diff -ruN linux-2.6.15-1/kernel/power/main.c build-2.6.15.1/kernel/power/main.c
diff -ruN linux-2.6.15-1/kernel/power/Makefile build-2.6.15.1/kernel/power/Makefile
diff -ruN linux-2.6.15-1/kernel/power/netlink.c build-2.6.15.1/kernel/power/netlink.c
--- linux-2.6.15-1/kernel/power/netlink.c 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/netlink.c 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,365 @@
+/*
+ * netlink.c
+ *
+ * Functions for communicating with a userspace helper via netlink.
+ */
With Rafael's solution, you don't need to inform userspace of your
progress -- because userspace is controlling the suspend. Snip 300
unneeded lines.
+static int suspend2_nl_gen_rcv_msg(struct user_helper_data *uhd,
+ struct sk_buff *skb, struct nlmsghdr *nlh)
+{
+ int type;
+ int *data;
+ int err;
+
+ /* Let the more specific handler go first. It returns
+ * 1 for valid messages that it doesn't know. */
+ if ((err = uhd->rcv_msg(skb, nlh)) != 1)
+ return err;
...some of them pretty cryptic.
+static int launch_userpace_program(struct user_helper_data *uhd)
+{
+ int retval;
+ static char *envp[] = {
+ "HOME=/",
+ "TERM=linux",
+ "PATH=/sbin:/usr/sbin:/bin:/usr/bin",
+ NULL };
+ static char *argv[] = { NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL };
+ char *channel = kmalloc(6, GFP_KERNEL);
+ int arg = 0, size;
+ char test_read[255];
+ char *orig_posn = uhd->program;
+
+ if (!strlen(orig_posn))
+ return 1;
+
+ while (arg < 7) {
+ sscanf(orig_posn, "%s", test_read);
+ size = strlen(test_read);
+ if (!(size))
+ break;
+ argv[arg] = kmalloc(size + 1, GFP_ATOMIC);
+ strcpy(argv[arg], test_read);
+ orig_posn += size + 1;
+ *test_read = 0;
+ arg++;
+ }
+
+ sprintf(channel, "-c%d", uhd->netlink_id);
+ argv[arg] = channel;
+
+ retval = call_usermodehelper(argv[0], argv, envp, 0);
It is really better if userspace calls you...
diff -ruN linux-2.6.15-1/kernel/power/netlink.h build-2.6.15.1/kernel/power/netlink.h
diff -ruN linux-2.6.15-1/kernel/power/pagedir.c build-2.6.15.1/kernel/power/pagedir.c
--- linux-2.6.15-1/kernel/power/pagedir.c 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/pagedir.c 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,370 @@
+/*
+ * kernel/power/pagedir.c
+ *
+ * Copyright (C) 1998-2001 Gabor Kuti <[email protected]>
+ * Copyright (C) 1998,2001,2002 Pavel Machek <[email protected]>
+ * Copyright (C) 2002-2003 Florent Chabaud <[email protected]>
+ * Copyright (C) 2002-2005 Nigel Cunningham <[email protected]>
+ *
+ * This file is released under the GPLv2.
+ *
+ * Routines for handling pagesets.
+ * Note that pbes aren't actually stored as such. They're stored as
+ * bitmaps and extents.
+ */
You should be able to use existing snapshotting...
+#include <linux/suspend.h>
+#include <linux/highmem.h>
+#include <linux/bootmem.h>
+#include <linux/hardirq.h>
+
+#include "pageflags.h"
+#include "ui.h"
+#include "pagedir.h"
+
+int extra_pagedir_pages_allocated = 0;
Do not zero-initialize static variables.
diff -ruN linux-2.6.15-1/kernel/power/pagedir.h build-2.6.15.1/kernel/power/pagedir.h
diff -ruN linux-2.6.15-1/kernel/power/pageflags.c build-2.6.15.1/kernel/power/pageflags.c
--- linux-2.6.15-1/kernel/power/pageflags.c 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/pageflags.c 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,139 @@
+/*
+ * kernel/power/suspend2_core/pageflags.c
Wrong name.
+ * Copyright (C) 2004-2005 Nigel Cunningham <[email protected]>
+ *
+ * This file is released under the GPLv2.
+ *
+ * Routines for dynamically allocating and releasing bitmaps
+ * used as pseudo-pageflags.
+ *
+ * Arrays are not contiguous. The first sizeof(void *) bytes are
+ * the pointer to the next page in the bitmap. This allows us to
+ * 1) work under low memory conditions where order 0 might be all
+ * that's available
+ * 2) save the pages at suspend time, reload and relocate them as
+ * necessary at resume time without breaking anything (cf
+ * extent pages).
+ */
Why do you need this?
diff -ruN linux-2.6.15-1/kernel/power/pageflags.h build-2.6.15.1/kernel/power/pageflags.h
diff -ruN linux-2.6.15-1/kernel/power/plugins.c build-2.6.15.1/kernel/power/plugins.c
--- linux-2.6.15-1/kernel/power/plugins.c 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/plugins.c 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,312 @@
+/*
+ * kernel/power/plugins.c
+ *
+ * Copyright (C) 2004-2005 Nigel Cunningham <[email protected]>
+ *
+ */
Oh, my favourite.. These should really be in userspace. 300 lines +
180 lines in header.
diff -ruN linux-2.6.15-1/kernel/power/plugins.h build-2.6.15.1/kernel/power/plugins.h
diff -ruN linux-2.6.15-1/kernel/power/power.h build-2.6.15.1/kernel/power/power.h
/* References to section boundaries */
-extern const void __nosave_begin, __nosave_end;
+//extern const void __nosave_begin, __nosave_end;
Delete it if you want it gone...
diff -ruN linux-2.6.15-1/kernel/power/power_off.c build-2.6.15.1/kernel/power/power_off.c
--- linux-2.6.15-1/kernel/power/power_off.c 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/power_off.c 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,79 @@
+/*
+ * kernel/power/suspend2_core/power_off.c
Wrong name.
+void suspend_power_down(void)
+{
+ if (test_action_state(SUSPEND_REBOOT)) {
+ suspend2_prepare_status(DONT_CLEAR_BAR, "Ready to reboot.");
+ kernel_restart(NULL);
+ }
And we do not want UI code in kernel.
diff -ruN linux-2.6.15-1/kernel/power/power_off.h build-2.6.15.1/kernel/power/power_off.h
diff -ruN linux-2.6.15-1/kernel/power/prepare_image.c build-2.6.15.1/kernel/power/prepare_image.c
--- linux-2.6.15-1/kernel/power/prepare_image.c 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/prepare_image.c 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,753 @@
+/*
+ * kernel/power/prepare_image.c
+ *
+ * Copyright (C) 2003-2005 Nigel Cunningham <[email protected]>
+ *
+ * This file is released under the GPLv2.
+ *
+ * We need to eat memory until we can:
+ * 1. Perform the save without changing anything (RAM_NEEDED < max_pfn)
+ * 2. Fit it all in available space (active_writer->available_space() >=
+ * storage_needed())
+ * 3. Reload the pagedir and pageset1 to places that don't collide with their
+ * final destinations, not knowing to what extent the resumed kernel will
+ * overlap with the one loaded at boot time. I think the resumed kernel
+ * should overlap completely, but I don't want to rely on this as it is
+ * an unproven assumption. We therefore assume there will be no overlap at
+ * all (worse case).
+ * 4. Meet the user's requested limit (if any) on the size of the image.
+ * The limit is in MB, so pages/256 (assuming 4K pages).
+ *
+ */
There's existing code in kernel to do this, no?
diff -ruN linux-2.6.15-1/kernel/power/prepare_image.h build-2.6.15.1/kernel/power/prepare_image.h
diff -ruN linux-2.6.15-1/kernel/power/proc.c build-2.6.15.1/kernel/power/proc.c
--- linux-2.6.15-1/kernel/power/proc.c 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/proc.c 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,305 @@
+/*
+ * /kernel/power/proc.c
Spurious slash?
+ * Copyright (C) 2002-2005 Nigel Cunningham <[email protected]>
+ *
+ * This file is released under the GPLv2.
+ *
+ * This file contains support for proc entries for tuning Suspend2.
+ *
+ * We have a generic handler that deals with the most common cases, and
+ * hooks for special handlers to use.
+ */
Well, we probably do not want more junk in /proc. And this would not
be neccessary if (surprise) userspace controlled suspend. 300 lines
unneeeded, and 70 lines in header.
diff -ruN linux-2.6.15-1/kernel/power/process.c build-2.6.15.1/kernel/power/process.c
diff -ruN linux-2.6.15-1/kernel/power/proc.h build-2.6.15.1/kernel/power/proc.h
diff -ruN linux-2.6.15-1/kernel/power/snapshot.c build-2.6.15.1/kernel/power/snapshot.c
diff -ruN linux-2.6.15-1/kernel/power/storage.c build-2.6.15.1/kernel/power/storage.c
--- linux-2.6.15-1/kernel/power/storage.c 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/storage.c 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,323 @@
+/*
+ * kernel/power/storage.c
+ *
+ * Copyright (C) 2005 Nigel Cunningham <[email protected]>
+ *
+ * This file is released under the GPLv2.
+ *
+ * Routines for talking to a userspace program that manages storage.
+ *
+ * The kernel side:
+ * - starts the userspace program;
+ * - sends messages telling it when to open and close the connection;
+ * - tells it when to quit;
+ *
+ * The user space side:
+ * - passes messages regarding status;
Yep, if you do it all in userspace, this vanishes. 340 lines down.
diff -ruN linux-2.6.15-1/kernel/power/storage.h build-2.6.15.1/kernel/power/storage.h
diff -ruN linux-2.6.15-1/kernel/power/suspend2_common.h build-2.6.15.1/kernel/power/suspend2_common.h
diff -ruN linux-2.6.15-1/kernel/power/suspend2.h build-2.6.15.1/kernel/power/suspend2.h
--- linux-2.6.15-1/kernel/power/suspend2.h 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/suspend2.h 2006-01-23 21:38:28.000000000 +1000
+
+#define KB(x) ((x) << (PAGE_SHIFT - 10))
+#define MB(x) ((x) >> (20 - PAGE_SHIFT))
+
Eh, nice macros... this should be done for whole kernel or not t all.
diff -ruN linux-2.6.15-1/kernel/power/suspend_block_io.c build-2.6.15.1/kernel/power/suspend_block_io.c
--- linux-2.6.15-1/kernel/power/suspend_block_io.c 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/suspend_block_io.c 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,1086 @@
+/*
+ * block_io.c
Wrong name.
+ * Copyright 2004-2005 Nigel Cunningham <[email protected]>
+ *
+ * Distributed under GPLv2.
+ *
+ * This file contains block io functions for suspend2. These are
+ * used by the swapwriter and it is planned that they will also
+ * be used by the NFSwriter.
+ *
+ */
1080 lines that are not neccessary in uswsusp case, because we can
simply use existing read/write routines.
diff -ruN linux-2.6.15-1/kernel/power/suspend.c build-2.6.15.1/kernel/power/suspend.c
--- linux-2.6.15-1/kernel/power/suspend.c 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/suspend.c 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,1133 @@
+/*
+ * kernel/power/suspend2.c
Name?
+/* Compression ratio */
+__nosavedata unsigned long bytes_in = 0, bytes_out = 0;
+
Should not compression live in its own plugin?
diff -ruN linux-2.6.15-1/kernel/power/suspend_checksums.c build-2.6.15.1/kernel/power/suspend_checksums.c
--- linux-2.6.15-1/kernel/power/suspend_checksums.c 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/suspend_checksums.c 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,509 @@
Checksumming can live in userspace, 500 lines down.
diff -ruN linux-2.6.15-1/kernel/power/suspend_file.c build-2.6.15.1/kernel/power/suspend_file.c
--- linux-2.6.15-1/kernel/power/suspend_file.c 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/suspend_file.c 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,1077 @@
+/*
+ * Filewriter.c
Name?
Can happily live in userspace (using bmap), 1070 lines down.
diff -ruN linux-2.6.15-1/kernel/power/suspend.h build-2.6.15.1/kernel/power/suspend.h
diff -ruN linux-2.6.15-1/kernel/power/suspend_swap.c build-2.6.15.1/kernel/power/suspend_swap.c
--- linux-2.6.15-1/kernel/power/suspend_swap.c 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/suspend_swap.c 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,1213 @@
+/*
+ * Swapwriter.c
+ *
+ * Copyright 2004-2005 Nigel Cunningham <[email protected]>
+ *
+ * Distributed under GPLv2.
+ *
+ * This file encapsulates functions for usage of swap space as a
+ * backing store.
+ */
Should be possible to put into userspace, 1200 lines.
diff -ruN linux-2.6.15-1/kernel/power/swsusp.c build-2.6.15.1/kernel/power/swsusp.c
diff -ruN linux-2.6.15-1/kernel/power/swsusp.h build-2.6.15.1/kernel/power/swsusp.h
diff -ruN linux-2.6.15-1/kernel/power/ui.c build-2.6.15.1/kernel/power/ui.c
--- linux-2.6.15-1/kernel/power/ui.c 1970-01-01 10:00:00.000000000 +1000
+++ build-2.6.15.1/kernel/power/ui.c 2006-01-23 21:38:28.000000000 +1000
@@ -0,0 +1,853 @@
+/*
+ * kernel/power/ui.c
+ *
+ * Copyright (C) 1998-2001 Gabor Kuti <[email protected]>
+ * Copyright (C) 1998,2001,2002 Pavel Machek <[email protected]>
+ * Copyright (C) 2002-2003 Florent Chabaud <[email protected]>
+ * Copyright (C) 2002-2005 Nigel Cunningham <[email protected]>
+ *
+ * This file is released under the GPLv2.
+ *
+ * Routines for Suspend2's user interface.
+ *
+ * The user interface code talks to a userspace program via a
+ * netlink socket.
+ *
+ * The kernel side:
+ * - starts the userui program;
+ * - sends text messages and progress bar status;
+ *
+ * The user space side:
+ * - passes messages regarding user requests (abort, toggle reboot etc)
+ *
+ */
Userinterface in kernel. Great. Fortunately Rafael's code allows this
850 lines not to be needed.
+char suspend_wait_for_keypress(int timeout)
+{
+ int fd;
+ char key = '\0';
+ struct termios t, t_backup;
+
+ if (ui_helper_data.pid != -1) {
+ wait_for_key_via_userui();
+ key = ' ';
+ goto out;
+ }
+
+ /* We should be guaranteed /dev/console exists after populate_rootfs() in
+ * init/main.c
+ */
+ if ((fd = sys_open("/dev/console", O_RDONLY, 0)) < 0) {
+ printk("Couldn't open /dev/console.\n");
+ goto out;
+ }
...and you still do user interface in kernel, despite having userland
helper.
+/* abort_suspend
+ *
+ * Description: Begin to abort a cycle. If this wasn't at the user's request
+ * (and we're displaying output), tell the user why and wait for
+ * them to acknowledge the message.
+ * Arguments: A parameterised string (imagine this is printk) to display,
+ * telling the user why we're aborting.
+ */
+
+void abort_suspend(const char *fmt, ...)
+{
+ va_list args;
+ int printed_len = 0;
And your own printk... sweeet.
+ if (!test_result_state(SUSPEND_ABORTED)) {
+ if (!test_result_state(SUSPEND_ABORT_REQUESTED)) {
+ va_start(args, fmt);
+ printed_len = vsnprintf(local_printf_buf,
+ sizeof(local_printf_buf), fmt, args);
+ va_end(args);
+ if (ui_helper_data.pid != -1)
+ printed_len = sprintf(local_printf_buf + printed_len,
+ " (Press SPACE to continue)");
+ suspend2_prepare_status(CLEAR_BAR, local_printf_buf);
Even if you call userland for actuall printk(), this is still user
interface.
+#if defined(CONFIG_VT) || defined(CONFIG_SERIAL_CONSOLE)
+ console_loglevel = 7;
+
+ say("=== Suspend2 ===\n\n");
+ if (warning_reason) {
+ say("BIG FAT WARNING!! %s\n\n", local_printf_buf);
+ switch (message_detail) {
+ case 0:
+ say("If you continue booting, note that any image WILL NOT BE REMOVED.\n");
+ say("Suspend is unable to do so because the appropriate modules aren't\n");
+ say("loaded. You should manually remove the image to avoid any\n");
+ say("possibility of corrupting your filesystem(s) later.\n");
+ break;
+ case 1:
+ say("If you want to use the current suspend image, reboot and try\n");
+ say("again with the same kernel that you suspended from. If you want\n");
+ say("to forget that image, continue and the image will be erased.\n");
+ break;
+ }
+ say("Press SPACE to reboot or C to continue booting with this kernel\n\n");
+ say("Default action if you don't select one in %d seconds is: %s.\n",
+ message_timeout,
+ default_answer == SUSPEND_CONTINUE_REQ ?
+ "continue booting" : "reboot");
+ } else {
+ say("BIG FAT WARNING!!\n\n");
+ say("You have tried to resume from this image before.\n");
+ say("If it failed once, it may well fail again.\n");
+ say("Would you like to remove the image and boot normally?\n");
+ say("This will be equivalent to entering noresume2 on the\n");
+ say("kernel command line.\n\n");
+ say("Press SPACE to remove the image or C to continue resuming.\n\n");
+ say("Default action if you don't select one in %d seconds is: %s.\n",
+ message_timeout,
+ !!default_answer ?
+ "continue resuming" : "remove the image");
+ }
Wonderful. Did not we agree that this has no place in kernel?
+ { .filename = "userui_progress_granularity",
+ .permissions = PROC_RW,
+ .type = SUSPEND_PROC_DATA_INTEGER,
+ .data = {
+ .integer = {
+ .variable = &progress_granularity,
+ .minimum = 1,
+ .maximum = 2048,
+ }
+ }
+ },
So even progress granularity is configurable?
diff -ruN linux-2.6.15-1/kernel/power/ui.h build-2.6.15.1/kernel/power/ui.h
diff -ruN linux-2.6.15-1/kernel/power/version.h build-2.6.15.1/kernel/power/version.h
diff -ruN linux-2.6.15-1/kernel/sched.c build-2.6.15.1/kernel/sched.c
diff -ruN linux-2.6.15-1/kernel/signal.c build-2.6.15.1/kernel/signal.c
diff -ruN linux-2.6.15-1/kernel/softirq.c build-2.6.15.1/kernel/softirq.c
diff -ruN linux-2.6.15-1/kernel/sys.c build-2.6.15.1/kernel/sys.c
--- linux-2.6.15-1/kernel/sys.c 2006-01-03 15:08:48.000000000 +1000
+++ build-2.6.15.1/kernel/sys.c 2006-01-23 21:38:28.000000000 +1000
@@ -173,15 +173,18 @@
{
int ret=NOTIFY_DONE;
struct notifier_block *nb = *n;
+ struct notifier_block *next;
while(nb)
{
- ret=nb->notifier_call(nb,val,v);
+ /* Determining next here allows the notifier to unregister itself */
+ next = nb->next;
+ ret = nb->notifier_call(nb,val,v);
if(ret&NOTIFY_STOP_MASK)
{
return ret;
}
- nb=nb->next;
+ nb = next;
}
return ret;
}
What is this?
diff -ruN linux-2.6.15-1/kernel/workqueue.c build-2.6.15.1/kernel/workqueue.c
diff -ruN linux-2.6.15-1/lib/dyn_pageflags.c build-2.6.15.1/lib/dyn_pageflags.c
diff -ruN linux-2.6.15-1/lib/Kconfig build-2.6.15.1/lib/Kconfig
diff -ruN linux-2.6.15-1/lib/Makefile build-2.6.15.1/lib/Makefile
diff -ruN linux-2.6.15-1/lib/vsprintf.c build-2.6.15.1/lib/vsprintf.c
diff -ruN linux-2.6.15-1/mm/bootmem.c build-2.6.15.1/mm/bootmem.c
diff -ruN linux-2.6.15-1/mm/memory.c build-2.6.15.1/mm/memory.c
--- linux-2.6.15-1/mm/memory.c 2006-01-03 15:08:49.000000000 +1000
+++ build-2.6.15.1/mm/memory.c 2006-01-23 21:38:28.000000000 +1000
@@ -950,6 +950,15 @@
return page;
}
+/*
+ * We want the address of the page for Suspend2 to mark as being in pageset1.
+ */
+
+struct page *suspend2_follow_page(struct mm_struct *mm, unsigned long address)
+{
+ return follow_page(mm->mmap, address, 0);
+}
+
int get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
unsigned long start, int len, int write, int force,
struct page **pages, struct vm_area_struct **vmas)
In mm/memory.c? It has a comment, unfortunately it does not say
anything.
diff -ruN linux-2.6.15-1/mm/page_alloc.c build-2.6.15.1/mm/page_alloc.c
--- linux-2.6.15-1/mm/page_alloc.c 2006-01-03 15:08:49.000000000 +1000
+++ build-2.6.15.1/mm/page_alloc.c 2006-01-23 21:38:28.000000000 +1000
@@ -920,8 +921,8 @@
/* This allocation should allow future memory freeing. */
- if (((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE)))
- && !in_interrupt()) {
+ if ((((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE))) &&
+ !in_interrupt()) || (test_freezer_state(FREEZER_ON))) {
if (!(gfp_mask & __GFP_NOMEMALLOC)) {
nofail_alloc:
/* go through the zonelist yet again, ignoring mins */
You have just made memory allocation slower. Oops.
diff -ruN linux-2.6.15-1/mm/pdflush.c build-2.6.15.1/mm/pdflush.c
diff -ruN linux-2.6.15-1/mm/swapfile.c build-2.6.15.1/mm/swapfile.c
diff -ruN linux-2.6.15-1/mm/vmscan.c build-2.6.15.1/mm/vmscan.c
diff -ruN linux-2.6.15-1/net/rxrpc/krxiod.c build-2.6.15.1/net/rxrpc/krxiod.c
diff -ruN linux-2.6.15-1/net/rxrpc/krxsecd.c build-2.6.15.1/net/rxrpc/krxsecd.c
diff -ruN linux-2.6.15-1/net/rxrpc/krxtimod.c build-2.6.15.1/net/rxrpc/krxtimod.c
diff -ruN linux-2.6.15-1/net/sunrpc/sched.c build-2.6.15.1/net/sunrpc/sched.c
diff -ruN linux-2.6.15-1/net/sunrpc/svcsock.c build-2.6.15.1/net/sunrpc/svcsock.c
So... I'm spreading FUD and suspend2 is not intrusive? I'd not say so.
And you claimed that uswsusp can not solve anything? With above
analysis, at least 8040 lines can be moved into userspace. That's more
than half of your patch...
Do we do anything really fundamental in userspace? No. Do you do
anything fundamental in those 8040 lines? No. => userspace, please.
Now, suspend2 is quite a lot of old code, that does not properly use
existing kernel infrastructure. Rather than trying to prove suspend2
is not intrusive (*)... can you just start using Rafael's existing
code, and put that code into userspace?
Pavel
(*) it is hard to prove something that is not true.
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi.
On Monday 20 February 2006 07:29, Pavel Machek wrote:
> Hi!
>
> > > swsusp is also available today, and works better than you think. It is
> > > slightly slower, but has all the other
> > > features you listed in 2.6.16-rc3.
> >
> > It is a lot slower because it does all it's I/O synchronously, doesn't
> > compress the image and throws away memory until at least half is
> > free.
>
> uswsusp does compress image (20% speedup, in recent CVS) and do
> asynchronous I/O.
Only 20? You must be doing something horribly wrong. Asynchronous I/O shoudl
get the speed from whatever you're getting without it to the maximum the
drive can handle. LZF should double the speed again on a CPU that's fast
enough that the bottleneck is the disk.
> > > > The only con I see is the complexity of the code, but then again,
> > > > Nigel
> > >
> > > ..but thats a big con.
> >
> > It's fud. Hopefully as I post more suspend2 patches to LKML, people will
> > see that Suspend2 is simpler than what you are planning.
>
> For what I'm planning, all the neccessary patches are already in -mm
> tree. And they are *really* simple. If you can get suspend2 to 1000
> lines of code (like Rafael did with uswsusp), we can have something to
> talk about.
Turn it round the right way. If you can get the functionality of Suspend2
using userspace only, then we have something to talk about.
> > > > From a user, and contributor, point of view, I really do not
> > > > understand why not even trying to push a working implementation into
> > > > mainline (I know that you cannot just apply the Suspend 2 patches and
> > > > shipping it,
> > >
> > > It is less work to port suspend2's features into userspace than to make
> > > suspend2 acceptable to mainline. Both will mean big changes, and may
> > > cause some short-term problems, but it will be less pain than
> > > maintaining suspend2 forever. Please help with the former...
> >
> > That's not true. I've taken time to look at what would be involved in
> > making suspend2 match the changes you're doing, and I've decided it's
> > just not worth the effort.
> >
> > Let's be clear. uswsusp is not really moving suspend-to-disk to
> > userspace. What it is doing is leaving everything but some code for
> > writing the image in kernel space, and implementing ioctls to give a
> > userspace program the ability to request that other processes be frozen,
> > the snapshot prepared and so on. Pages in the snapshot are copied to
> > userspace, possibly compressed or encrypted there in future, then fed
> > back to kernel space so it can use the swap routines to do the writing.
> > Very little of substance is being done in userspace. In short, all it's
> > doing is adding the complexity of
>
> Maybe very little of substance is being done in userspace, but all the
> uglyness can stay there. I no longer need LZF in kernel, special
> netlink API for progress bar (progress bar naturally lives in
> userland), no plugin infrastructure needed, etc.
And you do need?...
> If you can do suspend2 without putting stuff listed above into kernel,
> and in acceptable ammount of code... we can see. But you should really
> put suspend2 code into userspace, and be done with that. Feel free to
> spam l-k a bit more, but using existing infrastructure in -mm is right
> way to go, and it is easier, too.
It is only easier because you're not comparing apples with apples. I have no
desire to spam LKML with this pointless discussion, so I'm just going to get
on with submitting patches for review.
Rgards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On Ne 19-02-06 19:35:36, Dmitry Torokhov wrote:
> On Sunday 19 February 2006 18:42, Pavel Machek wrote:
> > --- linux-2.6.15-1/drivers/input/serio/serio.c??2006-01-03 15:08:26.000000000 +1000
> > +++ build-2.6.15.1/drivers/input/serio/serio.c??2006-01-23 21:38:28.000000000 +1000
> > @@ -314,6 +314,12 @@
> > ?
> > ????????????????serio_remove_duplicate_events(event);
> > ????????????????serio_free_event(event);
> > +
> > +???????????????if (unlikely(todo_list_active())) {
> > + ??????????????????????up(&serio_sem);
> > +???????????????????????try_todo_list();
> > + ??????????????????????down(&serio_sem);
> > +???????????????}
> > ????????}
> > ?
> > ????????up(&serio_sem);
> >
> > What is this?
> >
>
> I think it is a leftover from when serio and gameport cores were not
> "swsusp friendly" and were not releasing semaphore untill all pending
> messages have been processed. If you remember swsusp used to fail in
> this case. It can be safely dropped now.
>
> Overall as you noted alot of changes in Nigel's patch are useable outside
> of swsuspend2 so it's intrusiveness is not as big as you making it appear.
Yes, some of them are usaeable outside. But many of them were
attempted outside and vetoed for whatever reason :-(.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi!
> > > It is a lot slower because it does all it's I/O synchronously, doesn't
> > > compress the image and throws away memory until at least half is
> > > free.
> >
> > uswsusp does compress image (20% speedup, in recent CVS) and do
> > asynchronous I/O.
>
> Only 20? You must be doing something horribly wrong. Asynchronous
20% is speedup for compression alone, over whole suspend
process. Device suspend/resume takes lot of time in recent kernels.
> > > > > The only con I see is the complexity of the code, but then again,
> > > > > Nigel
> > > >
> > > > ..but thats a big con.
> > >
> > > It's fud. Hopefully as I post more suspend2 patches to LKML, people will
> > > see that Suspend2 is simpler than what you are planning.
> >
> > For what I'm planning, all the neccessary patches are already in -mm
> > tree. And they are *really* simple. If you can get suspend2 to 1000
> > lines of code (like Rafael did with uswsusp), we can have something to
> > talk about.
>
> Turn it round the right way. If you can get the functionality of Suspend2
> using userspace only, then we have something to talk about.
Only feature I can't do is "save whole pagecache"... and 14000 lines
of code for _that_ is a bit too much. I could probably patch my kernel
to dump pagecache to userspace, but I do not think it is worth the
effort.
> > > Let's be clear. uswsusp is not really moving suspend-to-disk to
> > > userspace. What it is doing is leaving everything but some code for
> > > writing the image in kernel space, and implementing ioctls to give a
> > > userspace program the ability to request that other processes be frozen,
> > > the snapshot prepared and so on. Pages in the snapshot are copied to
> > > userspace, possibly compressed or encrypted there in future, then fed
> > > back to kernel space so it can use the swap routines to do the writing.
> > > Very little of substance is being done in userspace. In short, all it's
> > > doing is adding the complexity of
> >
> > Maybe very little of substance is being done in userspace, but all the
> > uglyness can stay there. I no longer need LZF in kernel, special
> > netlink API for progress bar (progress bar naturally lives in
> > userland), no plugin infrastructure needed, etc.
>
> And you do need?...
I do not need anything more than what is already in -mm tree.
> > If you can do suspend2 without putting stuff listed above into kernel,
> > and in acceptable ammount of code... we can see. But you should really
> > put suspend2 code into userspace, and be done with that. Feel free to
> > spam l-k a bit more, but using existing infrastructure in -mm is right
> > way to go, and it is easier, too.
>
> It is only easier because you're not comparing apples with apples. I have no
> desire to spam LKML with this pointless discussion, so I'm just going to get
> on with submitting patches for review.
So please take my comments from "suspend2 review" mail into account.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi.
On Monday 20 February 2006 09:42, Pavel Machek wrote:
> Hi!
>
> > > > The only con I see is the complexity of the code, but then again,
> > > > Nigel
> > >
> > > ..but thats a big con.
> >
> > It's fud. Hopefully as I post more suspend2 patches to LKML, people will
> > see that Suspend2 is simpler than what you are planning.
>
> Well, good luck with that. But since you claimed I'm spreading FUD, I
> think I'll have to go through your patch.
>
> Ouch, it is 500KB, 19K lines. How can you claim it is not complex?!
Size != complexity. Not necessarily.
> Lets see what can be done in userspace from that big patch.
Thanks for finally giving some technical feedback.
> diff -ruN linux-2.6.15-1/arch/arm/kernel/signal.c
> build-2.6.15.1/arch/arm/kernel/signal.c ---
> linux-2.6.15-1/arch/arm/kernel/signal.c 2006-01-03 15:08:24.000000000 +1000
> +++ build-2.6.15.1/arch/arm/kernel/signal.c 2006-01-23 21:38:28.000000000
> +1000 @@ -637,7 +637,7 @@
> if (!user_mode(regs))
> return 0;
>
> - if (try_to_freeze())
> + if (try_todo_list())
> goto no_signal;
>
> if (current->ptrace & PT_SINGLESTEP)
>
> Unrelated to suspend2; either push it or drop it. [There are more such
> changes, even for architectures you do not support suspend on... or do
> you support suspend on h8300?]
This is because you got 2.2 instead of the latest-devel patch. It (and some
changes mentioned below) are got now (2.2.0.1).
> diff -ruN linux-2.6.15-1/arch/frv/kernel/signal.c
> build-2.6.15.1/arch/frv/kernel/signal.c diff -ruN
> linux-2.6.15-1/arch/h8300/kernel/signal.c
> build-2.6.15.1/arch/h8300/kernel/signal.c diff -ruN
> linux-2.6.15-1/arch/i386/kernel/io_apic.c
> build-2.6.15.1/arch/i386/kernel/io_apic.c diff -ruN
> linux-2.6.15-1/arch/i386/kernel/signal.c
> build-2.6.15.1/arch/i386/kernel/signal.c
>
> Same here.
>
> diff -ruN linux-2.6.15-1/arch/arm/mm/init.c
> build-2.6.15.1/arch/arm/mm/init.c
>
> Ok, so you support arm.
Work in progress.
> diff -ruN linux-2.6.15-1/arch/i386/kernel/time.c
> build-2.6.15.1/arch/i386/kernel/time.c ---
> linux-2.6.15-1/arch/i386/kernel/time.c 2006-01-03 15:08:25.000000000 +1000
> +++ build-2.6.15.1/arch/i386/kernel/time.c 2006-01-23 21:38:28.000000000
> +1000 @@ -372,7 +372,8 @@
> mod_timer(&sync_cmos_timer, jiffies + 1);
> }
>
> -static long clock_cmos_diff, sleep_start;
> +static long clock_cmos_diff;
> +static unsigned long sleep_start;
>
> static struct timer_opts *last_timer;
> static int timer_suspend(struct sys_device *dev, pm_message_t state)
> @@ -380,9 +381,11 @@
> /*
> * Estimate time zone so that set_time can update the clock
> */
> - clock_cmos_diff = -get_cmos_time();
> + long cmos_time = __get_cmos_time();
> +
> + clock_cmos_diff = -cmos_time;
> clock_cmos_diff += get_seconds();
> - sleep_start = get_cmos_time();
> + sleep_start = cmos_time;
> last_timer = cur_timer;
> cur_timer = &timer_none;
> if (last_timer->suspend)
> @@ -395,14 +398,16 @@
> unsigned long flags;
> unsigned long sec;
> unsigned long sleep_length;
> + unsigned long cmos_time;
>
> #ifdef CONFIG_HPET_TIMER
> if (is_hpet_enabled())
> hpet_reenable();
> #endif
> + cmos_time = get_cmos_time();
> + sec = cmos_time + clock_cmos_diff;
> + sleep_length = (cmos_time - sleep_start) * HZ;
> setup_pit_timer();
> - sec = get_cmos_time() + clock_cmos_diff;
> - sleep_length = (get_cmos_time() - sleep_start) * HZ;
> write_seqlock_irqsave(&xtime_lock, flags);
> xtime.tv_sec = sec;
> xtime.tv_nsec = 0;
>
> What problem does it solve? Do you want it in mainline? Unrelated to
> suspend2.
I've discussed it with John Stultz, and intend to do so some more.
> diff -ruN linux-2.6.15-1/arch/i386/mm/init.c
> build-2.6.15.1/arch/i386/mm/init.c diff -ruN
> linux-2.6.15-1/arch/m32r/kernel/signal.c
> build-2.6.15.1/arch/m32r/kernel/signal.c diff -ruN
> linux-2.6.15-1/arch/mips/kernel/irixsig.c
> build-2.6.15.1/arch/mips/kernel/irixsig.c diff -ruN
> linux-2.6.15-1/arch/mips/kernel/signal32.c
> build-2.6.15.1/arch/mips/kernel/signal32.c diff -ruN
> linux-2.6.15-1/arch/powerpc/kernel/signal_32.c
> build-2.6.15.1/arch/powerpc/kernel/signal_32.c diff -ruN
> linux-2.6.15-1/arch/ppc/mm/init.c build-2.6.15.1/arch/ppc/mm/init.c diff
> -ruN linux-2.6.15-1/arch/ppc/platforms/pmac_feature.c
> build-2.6.15.1/arch/ppc/platforms/pmac_feature.c diff -ruN
> linux-2.6.15-1/arch/sh/kernel/signal.c
> build-2.6.15.1/arch/sh/kernel/signal.c diff -ruN
> linux-2.6.15-1/arch/sh64/kernel/signal.c
> build-2.6.15.1/arch/sh64/kernel/signal.c diff -ruN
> linux-2.6.15-1/arch/x86_64/kernel/asm-offsets.c
> build-2.6.15.1/arch/x86_64/kernel/asm-offsets.c ---
> linux-2.6.15-1/arch/x86_64/kernel/asm-offsets.c 2006-01-03
> 15:08:25.000000000 +1000 +++
> build-2.6.15.1/arch/x86_64/kernel/asm-offsets.c 2006-01-23
> 21:38:28.000000000 +1000 @@ -61,8 +61,10 @@
> offsetof (struct rt_sigframe32, uc.uc_mcontext));
> BLANK();
> #endif
> +#ifdef CONFIG_PM
> DEFINE(pbe_address, offsetof(struct pbe, address));
> DEFINE(pbe_orig_address, offsetof(struct pbe, orig_address));
> DEFINE(pbe_next, offsetof(struct pbe, next));
> +#endif
> return 0;
> }
>
> Do we want this in mailine?
Gone in 2.2.0.1.
> diff -ruN linux-2.6.15-1/arch/x86_64/kernel/e820.c
> build-2.6.15.1/arch/x86_64/kernel/e820.c diff -ruN
> linux-2.6.15-1/arch/x86_64/kernel/signal.c
> build-2.6.15.1/arch/x86_64/kernel/signal.c
>
> diff -ruN linux-2.6.15-1/arch/x86_64/kernel/suspend.c
> build-2.6.15.1/arch/x86_64/kernel/suspend.c
>
> With uswsusp, you are using existing code...
If I could use your existing code, I would. Unfortunately I'm using a more
compact method of storing the data (bitmaps), and I reckon I have zero chance
of getting you to switch.
> --- linux-2.6.15-1/arch/x86_64/kernel/suspend.c 2006-01-03
> 15:08:25.000000000 +1000 +++
> build-2.6.15.1/arch/x86_64/kernel/suspend.c 2006-01-23 21:38:28.000000000
> +1000 @@ -141,7 +144,7 @@
>
> }
>
> -#ifdef CONFIG_SOFTWARE_SUSPEND
> +#if defined(CONFIG_SOFTWARE_SUSPEND)
> /* Defined in arch/x86_64/kernel/suspend_asm.S */
> extern int restore_image(void);
>
> @@ -220,4 +223,5 @@
> restore_image();
> return 0;
> }
> +
> #endif /* CONFIG_SOFTWARE_SUSPEND */
>
> Why such spurious changes?
Leftovers from previously trying #if defined(CONFIG_SOFTWARE_SUSPEND) ||
defined(CONFIG_SUSPEND2). Already cleaned up in 2.2.0.1.
> diff -ruN linux-2.6.15-1/arch/x86_64/kernel/time.c
> build-2.6.15.1/arch/x86_64/kernel/time.c ---
> linux-2.6.15-1/arch/x86_64/kernel/time.c 2006-01-03 15:08:25.000000000
> +1000 +++ build-2.6.15.1/arch/x86_64/kernel/time.c 2006-01-23
> 21:38:28.000000000 +1000 @@ -509,11 +509,56 @@
> return cycles_2_ns(a);
> }
>
> +unsigned long __get_cmos_time(void)
> +{
> + unsigned int year, mon, day, hour, min, sec;
> +
> + /*
> + * Do we need the spinlock in here too?
> + *
> + * If we're called directly (not via get_cmos_time),
> + * we're in the middle of a sysdev suspend/resume
> + * and interrupts are disabled, so this
> + * should be safe without any locking.
> + * -- NC
> + */
> +
> + do {
> + sec = CMOS_READ(RTC_SECONDS);
> + min = CMOS_READ(RTC_MINUTES);
> + hour = CMOS_READ(RTC_HOURS);
> + day = CMOS_READ(RTC_DAY_OF_MONTH);
> + mon = CMOS_READ(RTC_MONTH);
> + year = CMOS_READ(RTC_YEAR);
> + } while (sec != CMOS_READ(RTC_SECONDS));
> +
> + /*
> + * We know that x86-64 always uses BCD format, no need to check the
> config + * register.
> + */
> +
> + BCD_TO_BIN(sec);
> + BCD_TO_BIN(min);
> + BCD_TO_BIN(hour);
> + BCD_TO_BIN(day);
> + BCD_TO_BIN(mon);
> + BCD_TO_BIN(year);
> +
> + /*
> + * This will work up to Dec 31, 2069.
> + */
> +
> + if ((year += 1900) < 1970)
> + year += 100;
> +
> + return mktime(year, mon, day, hour, min, sec);
> +}
> +
> unsigned long get_cmos_time(void)
> {
> - unsigned int timeout, year, mon, day, hour, min, sec;
> + unsigned int timeout;
> unsigned char last, this;
> - unsigned long flags;
> + unsigned long flags, result;
>
> /*
> * The Linux interpretation of the CMOS clock register contents: When the
> @@ -534,39 +579,10 @@
> timeout--;
> }
>
> -/*
> - * Here we are safe to assume the registers won't change for a whole
> second, so - * we just go ahead and read them.
> - */
> -
> - sec = CMOS_READ(RTC_SECONDS);
> - min = CMOS_READ(RTC_MINUTES);
> - hour = CMOS_READ(RTC_HOURS);
> - day = CMOS_READ(RTC_DAY_OF_MONTH);
> - mon = CMOS_READ(RTC_MONTH);
> - year = CMOS_READ(RTC_YEAR);
> -
> + result = __get_cmos_time();
> spin_unlock_irqrestore(&rtc_lock, flags);
>
> -/*
> - * We know that x86-64 always uses BCD format, no need to check the config
> - * register.
> - */
> -
> - BCD_TO_BIN(sec);
> - BCD_TO_BIN(min);
> - BCD_TO_BIN(hour);
> - BCD_TO_BIN(day);
> - BCD_TO_BIN(mon);
> - BCD_TO_BIN(year);
> -
> -/*
> - * x86-64 systems only exists since 2002.
> - * This will work up to Dec 31, 2100
> - */
> - year += 2000;
> -
> - return mktime(year, mon, day, hour, min, sec);
> + return result;
> }
>
> #ifdef CONFIG_CPU_FREQ
> @@ -1004,7 +1020,7 @@
> /*
> * Estimate time zone so that set_time can update the clock
> */
> - long cmos_time = get_cmos_time();
> + long cmos_time = __get_cmos_time();
>
> clock_cmos_diff = -cmos_time;
> clock_cmos_diff += get_seconds();
>
> What does this do? Seems independend from rest of suspend2.
Discussing with John (see above).
> diff -ruN linux-2.6.15-1/arch/x86_64/mm/init.c
> build-2.6.15.1/arch/x86_64/mm/init.c diff -ruN
> linux-2.6.15-1/block/ll_rw_blk.c build-2.6.15.1/block/ll_rw_blk.c diff -ruN
> linux-2.6.15-1/crypto/deflate.c build-2.6.15.1/crypto/deflate.c ---
> linux-2.6.15-1/crypto/deflate.c 2006-01-03 15:08:25.000000000 +1000 +++
> build-2.6.15.1/crypto/deflate.c 2006-01-23 21:38:28.000000000 +1000 @@
> -143,8 +143,15 @@
>
> ret = zlib_deflate(stream, Z_FINISH);
> if (ret != Z_STREAM_END) {
> - ret = -EINVAL;
> - goto out;
> + if (!(ret == Z_OK && !stream->avail_in && !stream->avail_out)) {
> + ret = -EINVAL;
> + goto out;
> + } else {
> + u8 zerostuff = 0;
> + stream->next_out = &zerostuff;
> + stream->avail_out = 1;
> + ret = zlib_deflate(stream, Z_FINISH);
> + }
> }
> ret = 0;
> *dlen = stream->total_out;
>
> WTF is this?
The gzip cryptoapi plugin doesn't like decompressing a full page. There is
already a similar patch in the inflate code iirc. I
> diff -ruN linux-2.6.15-1/crypto/Kconfig build-2.6.15.1/crypto/Kconfig
> --- linux-2.6.15-1/crypto/Kconfig 2006-01-03 15:08:25.000000000 +1000
> +++ build-2.6.15.1/crypto/Kconfig 2006-01-23 21:38:28.000000000 +1000
> @@ -285,6 +285,13 @@
>
> You will most probably want this if using IPSec.
>
> +config CRYPTO_LZF
> + tristate "LZF compression algorithm"
> + depends on CRYPTO
> + help
> + This is the LZF algorithm. It is especially useful for Suspend2,
> + because it achieves good compression quickly.
> +
> config CRYPTO_MICHAEL_MIC
> tristate "Michael MIC keyed digest algorithm"
> depends on CRYPTO
> diff -ruN linux-2.6.15-1/crypto/lzf.c build-2.6.15.1/crypto/lzf.c
> diff -ruN linux-2.6.15-1/crypto/Makefile build-2.6.15.1/crypto/Makefile
>
> With uswsusp, LZF can stay in userspace.
>
> diff -ruN linux-2.6.15-1/Documentation/kernel-parameters.txt
> build-2.6.15.1/Documentation/kernel-parameters.txt ---
> linux-2.6.15-1/Documentation/kernel-parameters.txt 2006-01-03
> 15:08:24.000000000 +1000 +++
> build-2.6.15.1/Documentation/kernel-parameters.txt 2006-01-23
> 21:38:28.000000000 +1000 @@ -71,6 +71,7 @@
> SERIAL Serial support is enabled.
> SMP The kernel is an SMP kernel.
> SPARC Sparc architecture is enabled.
> + SUSPEND2 Suspend2 is enabled.
> SWSUSP Software suspend is enabled.
> TS Appropriate touchscreen support is enabled.
> USB USB support is enabled.
> @@ -966,6 +967,8 @@
> noresume [SWSUSP] Disables resume and restores original swap
> space.
>
> + noresume2 [SUSPEND2] Disables resuming and restores original swap
> signature. +
> no-scroll [VGA] Disables scrollback.
> This is required for the Braillex ib80-piezo Braille
> reader made by F.H. Papenmeier (Germany).
>
> ...and kernel parameters do not need to change...
This is only because I'm deliberately not stomping on your code at the moment.
> diff -ruN linux-2.6.15-1/Documentation/power/internals.txt
> build-2.6.15.1/Documentation/power/internals.txt ---
> linux-2.6.15-1/Documentation/power/internals.txt 1970-01-01
> 10:00:00.000000000 +1000 +++
> build-2.6.15.1/Documentation/power/internals.txt 2006-01-23
> 21:38:28.000000000 +1000 + Plugins are linked together in pipeline
> fashion. There may be zero or more + page transformers in a pipeline,
> and there is always exactly one writer. + The pipeline follows this
> pattern:
> +
> + ---------------------------------
> + | Suspend2 Core
> + ---------------------------------
>
> Notice missing '|'
Ta.
>
> + |
> + |
> + ---------------------------------
> + | Page transformer 1 |
> + ---------------------------------
> + |
> + |
> + ---------------------------------
> + | Page transformer 2 |
> + ---------------------------------
> + |
> + |
> + ---------------------------------
> + | Writer |
> + ---------------------------------
>
> Also notice that with uswsusp, this pipeline can stay in userspace.
>
> diff -ruN linux-2.6.15-1/Documentation/power/kernel_threads.txt
> build-2.6.15.1/Documentation/power/kernel_threads.txt diff -ruN
> linux-2.6.15-1/Documentation/power/suspend2.txt
> build-2.6.15.1/Documentation/power/suspend2.txt
>
> ...and extensive documentation can stay with userspace tools.
>
> diff -ruN linux-2.6.15-1/Documentation/power/swsusp.txt
> build-2.6.15.1/Documentation/power/swsusp.txt diff -ruN
> linux-2.6.15-1/drivers/acpi/osl.c build-2.6.15.1/drivers/acpi/osl.c ---
> linux-2.6.15-1/drivers/acpi/osl.c 2006-01-03 15:08:26.000000000 +1000 +++
> build-2.6.15.1/drivers/acpi/osl.c 2006-01-23 21:38:28.000000000 +1000 @@
> -91,7 +91,7 @@
> "Access to PCI configuration space unavailable\n");
> return AE_NULL_ENTRY;
> }
> - kacpid_wq = create_singlethread_workqueue("kacpid");
> + kacpid_wq = create_nofreeze_singlethread_workqueue("kacpid");
> BUG_ON(!kacpid_wq);
>
> return AE_OK;
>
> Big search and replace all over the tree. Changes the default to
> unsafe one. Do you ever listen to comments?
"Changes the default to unsafe one"? It makes the default to be freezing
kernel threads, which should be safer since they then won't unexpectedly do
(random action).
> diff -ruN linux-2.6.15-1/drivers/acpi/sleep/proc.c
> build-2.6.15.1/drivers/acpi/sleep/proc.c diff -ruN
> linux-2.6.15-1/drivers/base/power/resume.c
> build-2.6.15.1/drivers/base/power/resume.c ---
> linux-2.6.15-1/drivers/base/power/resume.c 2006-01-03 15:08:26.000000000
> +1000 +++ build-2.6.15.1/drivers/base/power/resume.c 2006-01-23
> 21:38:28.000000000 +1000 @@ -101,6 +101,11 @@
> list_del_init(entry);
> list_add_tail(entry, &dpm_active);
> resume_device(dev);
> + if (!irqs_disabled()) {
> + printk("WARNING: Interrupts reenabled while resuming sysdev driver
> %s.\n", + kobject_name(&dev->kobj));
> + local_irq_disable();
> + }
> put_device(dev);
> }
> }
>
> Nothing to do with suspend2. Either it is good idea or it is not, and
> I think I saw mails telling you it is not.
Yes. Changed in 2.2.0.1.
> diff -ruN linux-2.6.15-1/drivers/base/power/suspend.c
> build-2.6.15.1/drivers/base/power/suspend.c diff -ruN
> linux-2.6.15-1/drivers/base/sys.c build-2.6.15.1/drivers/base/sys.c
>
> ...but you still keep the bad patches in your tree.
Fixed in 2.2.0.1
> diff -ruN linux-2.6.15-1/drivers/block/pktcdvd.c
> build-2.6.15.1/drivers/block/pktcdvd.c
>
> diff -ruN linux-2.6.15-1/drivers/char/agp/agp_suspend.h
> build-2.6.15.1/drivers/char/agp/agp_suspend.h diff -ruN
> linux-2.6.15-1/drivers/char/agp/ati-agp.c
> build-2.6.15.1/drivers/char/agp/ati-agp.c diff -ruN
> linux-2.6.15-1/drivers/char/agp/nvidia-agp.c
> build-2.6.15.1/drivers/char/agp/nvidia-agp.c
>
> AGP stuff is independed with rest of code. Ahha, it was probably
> included in latest trees, but your diff is still against 2.6.15.
>
> diff -ruN linux-2.6.15-1/drivers/char/hvc_console.c
> build-2.6.15.1/drivers/char/hvc_console.c diff -ruN
> linux-2.6.15-1/drivers/char/hvcs.c build-2.6.15.1/drivers/char/hvcs.c diff
> -ruN linux-2.6.15-1/drivers/ieee1394/ieee1394_core.c
> build-2.6.15.1/drivers/ieee1394/ieee1394_core.c diff -ruN
> linux-2.6.15-1/drivers/ieee1394/nodemgr.c
> build-2.6.15.1/drivers/ieee1394/nodemgr.c diff -ruN
> linux-2.6.15-1/drivers/input/gameport/gameport.c
> build-2.6.15.1/drivers/input/gameport/gameport.c diff -ruN
> linux-2.6.15-1/drivers/input/serio/serio.c
> build-2.6.15.1/drivers/input/serio/serio.c ---
> linux-2.6.15-1/drivers/input/serio/serio.c 2006-01-03 15:08:26.000000000
> +1000 +++ build-2.6.15.1/drivers/input/serio/serio.c 2006-01-23
> 21:38:28.000000000 +1000 @@ -314,6 +314,12 @@
>
> serio_remove_duplicate_events(event);
> serio_free_event(event);
> +
> + if (unlikely(todo_list_active())) {
> + up(&serio_sem);
> + try_todo_list();
> + down(&serio_sem);
> + }
> }
>
> up(&serio_sem);
>
> What is this?
From Christoph's patch - gone in 2.2.0.1.
> diff -ruN linux-2.6.15-1/drivers/macintosh/Kconfig
> build-2.6.15.1/drivers/macintosh/Kconfig ---
> linux-2.6.15-1/drivers/macintosh/Kconfig 2006-01-03 15:08:26.000000000
> +1000 +++ build-2.6.15.1/drivers/macintosh/Kconfig 2006-01-23
> 21:38:28.000000000 +1000 @@ -192,4 +192,8 @@
> tristate "Support for ANS LCD display"
> depends on ADB_CUDA && PPC_PMAC
>
> +config SOFTWARE_REPLACE_SLEEP
> + bool "Using Software suspend replace broken sleep function"
> + depends on SUSPEND2
> +
> endmenu
>
> If sleep function is broken, why would you ever want it enabled? Why
> does this need to be configurable?
It gets unbroken if replaced with suspend2 (and I guess swsusp) :). This is
from Hugang's patch, so I'm not claiming expert knowledge on this bit.
> diff -ruN linux-2.6.15-1/drivers/macintosh/therm_adt746x.c
> build-2.6.15.1/drivers/macintosh/therm_adt746x.c diff -ruN
> linux-2.6.15-1/drivers/macintosh/via-pmu.c
> build-2.6.15.1/drivers/macintosh/via-pmu.c diff -ruN
> linux-2.6.15-1/drivers/md/dm-crypt.c build-2.6.15.1/drivers/md/dm-crypt.c
> diff -ruN linux-2.6.15-1/drivers/md/md.c build-2.6.15.1/drivers/md/md.c
> diff -ruN linux-2.6.15-1/drivers/media/dvb/dvb-core/dvb_frontend.c
> build-2.6.15.1/drivers/media/dvb/dvb-core/dvb_frontend.c diff -ruN
> linux-2.6.15-1/drivers/media/video/msp3400.c
> build-2.6.15.1/drivers/media/video/msp3400.c diff -ruN
> linux-2.6.15-1/drivers/media/video/tvaudio.c
> build-2.6.15.1/drivers/media/video/tvaudio.c diff -ruN
> linux-2.6.15-1/drivers/media/video/video-buf-dvb.c
> build-2.6.15.1/drivers/media/video/video-buf-dvb.c diff -ruN
> linux-2.6.15-1/drivers/net/8139too.c build-2.6.15.1/drivers/net/8139too.c
> diff -ruN linux-2.6.15-1/drivers/net/irda/sir_kthread.c
> build-2.6.15.1/drivers/net/irda/sir_kthread.c ---
> linux-2.6.15-1/drivers/net/irda/sir_kthread.c 2006-01-03 15:08:29.000000000
> +1000 +++ build-2.6.15.1/drivers/net/irda/sir_kthread.c 2006-01-23
> 21:38:28.000000000 +1000 @@ -112,6 +112,7 @@
> DECLARE_WAITQUEUE(wait, current);
>
> daemonize("kIrDAd");
> + current->flags |= PF_NOFREEZE;
>
> irda_rq_queue.thread = current;
>
> @@ -134,9 +135,6 @@
> __set_task_state(current, TASK_RUNNING);
> remove_wait_queue(&irda_rq_queue.kick, &wait);
>
> - /* make swsusp happy with our thread */
> - try_to_freeze();
> -
> run_irda_queue();
> }
>
>
> Why do you need irda threads running during suspend?
Not sure where that came from. Will revert.
> diff -ruN linux-2.6.15-1/drivers/net/irda/stir4200.c
> build-2.6.15.1/drivers/net/irda/stir4200.c diff -ruN
> linux-2.6.15-1/drivers/net/wireless/airo.c
> build-2.6.15.1/drivers/net/wireless/airo.c diff -ruN
> linux-2.6.15-1/drivers/pcmcia/cs.c build-2.6.15.1/drivers/pcmcia/cs.c diff
> -ruN linux-2.6.15-1/drivers/pnp/pnpbios/core.c
> build-2.6.15.1/drivers/pnp/pnpbios/core.c diff -ruN
> linux-2.6.15-1/drivers/scsi/hosts.c build-2.6.15.1/drivers/scsi/hosts.c
> diff -ruN linux-2.6.15-1/drivers/scsi/lpfc/lpfc_init.c
> build-2.6.15.1/drivers/scsi/lpfc/lpfc_init.c diff -ruN
> linux-2.6.15-1/drivers/usb/core/hub.c build-2.6.15.1/drivers/usb/core/hub.c
> diff -ruN linux-2.6.15-1/drivers/usb/gadget/file_storage.c
> build-2.6.15.1/drivers/usb/gadget/file_storage.c diff -ruN
> linux-2.6.15-1/drivers/usb/net/pegasus.c
> build-2.6.15.1/drivers/usb/net/pegasus.c diff -ruN
> linux-2.6.15-1/drivers/usb/storage/usb.c
> build-2.6.15.1/drivers/usb/storage/usb.c diff -ruN
> linux-2.6.15-1/drivers/w1/w1.c build-2.6.15.1/drivers/w1/w1.c diff -ruN
> linux-2.6.15-1/fs/afs/kafsasyncd.c build-2.6.15.1/fs/afs/kafsasyncd.c diff
> -ruN linux-2.6.15-1/fs/afs/kafstimod.c build-2.6.15.1/fs/afs/kafstimod.c
> diff -ruN linux-2.6.15-1/fs/jbd/journal.c build-2.6.15.1/fs/jbd/journal.c
> diff -ruN linux-2.6.15-1/fs/jffs/intrep.c build-2.6.15.1/fs/jffs/intrep.c
> diff -ruN linux-2.6.15-1/fs/jffs2/background.c
> build-2.6.15.1/fs/jffs2/background.c diff -ruN
> linux-2.6.15-1/fs/jfs/jfs_logmgr.c build-2.6.15.1/fs/jfs/jfs_logmgr.c diff
> -ruN linux-2.6.15-1/fs/jfs/jfs_txnmgr.c build-2.6.15.1/fs/jfs/jfs_txnmgr.c
> diff -ruN linux-2.6.15-1/fs/lockd/clntlock.c
> build-2.6.15.1/fs/lockd/clntlock.c diff -ruN
> linux-2.6.15-1/fs/lockd/clntproc.c build-2.6.15.1/fs/lockd/clntproc.c diff
> -ruN linux-2.6.15-1/fs/lockd/svc.c build-2.6.15.1/fs/lockd/svc.c diff -ruN
> linux-2.6.15-1/fs/xfs/linux-2.6/xfs_buf.c
> build-2.6.15.1/fs/xfs/linux-2.6/xfs_buf.c diff -ruN
> linux-2.6.15-1/fs/xfs/linux-2.6/xfs_super.c
> build-2.6.15.1/fs/xfs/linux-2.6/xfs_super.c
>
> So you run big search & replace all over the tree, making your diff
> huge. Either drop them or merge them...
That's the workqueue stuff, so it's not what you're thinking. There are a
number of routines that aren't changed.
> diff -ruN linux-2.6.15-1/include/asm-arm/hw_irq.h
> build-2.6.15.1/include/asm-arm/hw_irq.h ---
> linux-2.6.15-1/include/asm-arm/hw_irq.h 1970-01-01 10:00:00.000000000 +1000
> +++ build-2.6.15.1/include/asm-arm/hw_irq.h 2006-01-23 21:38:28.000000000
> +1000 @@ -0,0 +1,4 @@
> +#ifndef __ASM_HARDIRQ_H
> +#define __ASM_HARDIRQ_H
> +#include <asm/hardirq.h>
> +#endif
>
> What does this have to do with suspend2?
Not sure. I'll ask the guy who's working on the arm support.
> diff -ruN linux-2.6.15-1/include/asm-arm/suspend2.h
> build-2.6.15.1/include/asm-arm/suspend2.h diff -ruN
> linux-2.6.15-1/include/asm-i386/mach-default/mach_time.h
> build-2.6.15.1/include/asm-i386/mach-default/mach_time.h diff -ruN
> linux-2.6.15-1/include/asm-i386/suspend2.h
> build-2.6.15.1/include/asm-i386/suspend2.h ---
> linux-2.6.15-1/include/asm-i386/suspend2.h 1970-01-01 10:00:00.000000000
> +1000 +++ build-2.6.15.1/include/asm-i386/suspend2.h 2006-01-23
> 21:38:28.000000000 +1000 @@ -0,0 +1,288 @@
> + /*
> + * Copyright 2003-2005 Nigel Cunningham <[email protected]>
> + * Based on code
> + * Copyright 2001-2002 Pavel Machek <[email protected]>
> + * Based on code
> + * Copyright 2001 Patrick Mochel <[email protected]>
> + */
> +#include <linux/irq.h>
> +#include <asm/desc.h>
> +#include <asm/i387.h>
> +#include <asm/tlbflush.h>
> +#include <asm/desc.h>
> +#include <asm/processor.h>
> +
> +/* image of the saved processor states */
> +struct suspend2_saved_context {
> + u32 eax, ebx, ecx, edx;
> + u32 esp, ebp, esi, edi;
> + u16 es, fs, gs, ss;
> + u32 cr0, cr2, cr3, cr4;
> + u16 gdt_pad;
> + u16 gdt_limit;
> + u32 gdt_base;
> + u16 idt_pad;
> + u16 idt_limit;
> + u32 idt_base;
> + u16 ldt;
> + u16 tss;
> + u32 tr;
> + u32 safety;
> + u32 return_address;
> + u32 eflags;
> +} __attribute__((packed));
> +typedef struct suspend2_saved_context suspend2_saved_context_t;
> +
> +/* temporary storage */
> +extern struct suspend2_saved_context suspend2_saved_context;
> +
> +/*
> + * save_processor_context
> + *
> + * Save the state of the processor before we go to sleep.
> + *
> + * return_stack is the value of the stack pointer (%esp) as the caller
> sees it. + * A good way could not be found to obtain it from here (don't
> want to make + * _too_ many assumptions about the layout of the stack this
> far down.) Also, + * the handy little __builtin_frame_pointer(level) where
> level > 0, is blatantly + * buggy - it returns the value of the stack at
> the proper location, not the + * location, like it should (as of gcc
> 2.91.66)
> + *
> + * Note that the context and timing of this function is pretty critical.
> + * With a minimal amount of things going on in the caller and in here, gcc
> + * does a good job of being just a dumb compiler. Watch the assembly
> output + * if anything changes, though, and make sure everything is going
> in the right + * place.
> + */
> +static inline void suspend2_arch_save_processor_context(void)
> +{
> + kernel_fpu_begin();
> +
> + /*
> + * descriptor tables
> + */
> + asm volatile ("sgdt (%0)" : "=m" (suspend2_saved_context.gdt_limit));
> + asm volatile ("sidt (%0)" : "=m" (suspend2_saved_context.idt_limit));
> + asm volatile ("sldt (%0)" : "=m" (suspend2_saved_context.ldt));
> + asm volatile ("str (%0)" : "=m" (suspend2_saved_context.tr));
> +
> + /*
> + * save the general registers.
> + * note that gcc has constructs to specify output of certain registers,
> + * but they're not used here, because it assumes that you want to modify
> + * those registers, so it tries to be smart and save them beforehand.
> + * It's really not necessary, and kinda fishy (check the assembly
> output), + * so it's avoided.
> + */
> + asm volatile ("movl %%esp, (%0)" : "=m" (suspend2_saved_context.esp));
> + asm volatile ("movl %%eax, (%0)" : "=m" (suspend2_saved_context.eax));
> + asm volatile ("movl %%ebx, (%0)" : "=m" (suspend2_saved_context.ebx));
> + asm volatile ("movl %%ecx, (%0)" : "=m" (suspend2_saved_context.ecx));
> + asm volatile ("movl %%edx, (%0)" : "=m" (suspend2_saved_context.edx));
> + asm volatile ("movl %%ebp, (%0)" : "=m" (suspend2_saved_context.ebp));
> + asm volatile ("movl %%esi, (%0)" : "=m" (suspend2_saved_context.esi));
> + asm volatile ("movl %%edi, (%0)" : "=m" (suspend2_saved_context.edi));
> +
> + /*
> + * segment registers
> + */
> + asm volatile ("movw %%es, %0" : "=r" (suspend2_saved_context.es));
> + asm volatile ("movw %%fs, %0" : "=r" (suspend2_saved_context.fs));
> + asm volatile ("movw %%gs, %0" : "=r" (suspend2_saved_context.gs));
> + asm volatile ("movw %%ss, %0" : "=r" (suspend2_saved_context.ss));
> +
> + /*
> + * control registers
> + */
> + asm volatile ("movl %%cr0, %0" : "=r" (suspend2_saved_context.cr0));
> + asm volatile ("movl %%cr2, %0" : "=r" (suspend2_saved_context.cr2));
> + asm volatile ("movl %%cr3, %0" : "=r" (suspend2_saved_context.cr3));
> + asm volatile ("movl %%cr4, %0" : "=r" (suspend2_saved_context.cr4));
> +
> + /*
> + * eflags
> + */
> + asm volatile ("pushfl ; popl (%0)" : "=m"
> (suspend2_saved_context.eflags)); +}
>
> Can't you use existing suspend functions?
I'd like to. I've forgotten why I think I can't - will check it out again.
> Same for the rest of file...
>
> +static inline void suspend2_arch_flush_caches(void)
> +{
> +#ifdef CONFIG_SMP
> + cpu_clear(0, per_cpu(cpu_tlbstate,
> + 0).active_mm->cpu_vm_mask);
> +#endif
> + wbinvd();
> + __flush_tlb_all();
> +
> +}
> +
> +static inline void suspend2_arch_post_copyback(void)
> +{
> + BUG_ON(!irqs_disabled());
> +
> + current_cpu_data.loops_per_jiffy =
> + c_loops_per_jiffy_ref;
> +#ifndef CONFIG_SMP
> + loops_per_jiffy = c_loops_per_jiffy_ref;
> + cpu_khz = cpu_khz_ref;
> +#endif
> +}
> +
> +#endif
>
> What is this? Is your method of dealing with SMP different from
> mainline's?
It used to be (when I had SMP support and mainline didn't), and this is a
vestage thought was still useful. Since you ask, I'll look at it again.
> diff -ruN linux-2.6.15-1/include/asm-ppc/cpu_context.h
> build-2.6.15.1/include/asm-ppc/cpu_context.h diff -ruN
> linux-2.6.15-1/include/asm-x86_64/page.h
> build-2.6.15.1/include/asm-x86_64/page.h diff -ruN
> linux-2.6.15-1/include/asm-x86_64/suspend2.h
> build-2.6.15.1/include/asm-x86_64/suspend2.h
>
> Same here. You should be able to use mainline's snapshot
> functionality. That's common piece between swsusp and suspend2, and
> having your own copy helps noone.
As mentioned above, I use a different method of storing the meta data
(bitmaps). It's more space efficient, but I expect you won't want it because
it will make your asm longer.
> diff -ruN linux-2.6.15-1/include/asm-x86_64/suspend.h
> build-2.6.15.1/include/asm-x86_64/suspend.h diff -ruN
> linux-2.6.15-1/include/linux/bio.h build-2.6.15.1/include/linux/bio.h ---
> linux-2.6.15-1/include/linux/bio.h 2006-01-03 15:08:44.000000000 +1000 +++
> build-2.6.15.1/include/linux/bio.h 2006-01-23 21:38:28.000000000 +1000 @@
> -124,6 +124,7 @@
> #define BIO_BOUNCED 5 /* bio is a bounce bio */
> #define BIO_USER_MAPPED 6 /* contains user pages */
> #define BIO_EOPNOTSUPP 7 /* not supported */
> +#define BIO_SUSPEND2 8 /* Suspend2 bio - for corruption checking */
> #define bio_flagged(bio, flag) ((bio)->bi_flags & (1 << (flag)))
>
> /*
>
> You just should not corrupt the data...
Agreed. It wasn't Suspend corrupting the data that I was checking for, but
filesystems (XFS specifically) submitting I/O after freezing.
> diff -ruN linux-2.6.15-1/include/linux/dyn_pageflags.h
> build-2.6.15.1/include/linux/dyn_pageflags.h ---
> linux-2.6.15-1/include/linux/dyn_pageflags.h 1970-01-01 10:00:00.000000000
> +1000 +++ build-2.6.15.1/include/linux/dyn_pageflags.h 2006-01-23
> 21:38:28.000000000 +1000 @@ -0,0 +1,66 @@
> +
> +typedef unsigned long *** dyn_pageflags_t;
> +
>
> Eh....
>
> Could not you just use normal page flags like swsusp does?
As mentioned above, I use these pseudo-pageflags to store almost all the
metadata - which pages are to be saved, which are LRU, where they're to be
copied to and from for the atomic copy etc. If I used real pageflags, I'd
need four or five. This way, I leave the real ones free for people who really
need them. By using pseudo-pageflags, I also make serialising the metadata
much simpler (just another page to r/w).
> diff -ruN linux-2.6.15-1/include/linux/freezer.h
> build-2.6.15.1/include/linux/freezer.h ---
> linux-2.6.15-1/include/linux/freezer.h 1970-01-01 10:00:00.000000000 +1000
> +++ build-2.6.15.1/include/linux/freezer.h 2006-01-23 21:38:28.000000000
> +1000 @@ -0,0 +1,28 @@
> +/* Freezer declarations */
> +
> +#define FREEZER_ON 0
> +#define ABORT_FREEZING 1
> +
> +#define FREEZER_KERNEL_THREADS 0
> +#define FREEZER_ALL_THREADS 1
> +
> +#ifdef CONFIG_PM
> +extern unsigned long freezer_state;
> +
> +#define test_freezer_state(bit) test_bit(bit, &freezer_state)
> +#define set_freezer_state(bit) set_bit(bit, &freezer_state)
> +#define clear_freezer_state(bit) clear_bit(bit, &freezer_state)
> +
> +#define freezer_is_on() (test_freezer_state(FREEZER_ON))
> +
> +extern void do_freeze_process(struct notifier_block *nl);
> +
> +#else
> +
> +#define test_freezer_state(bit) (0)
> +#define set_freezer_state(bit) do { } while(0)
> +#define clear_freezer_state(bit) do { } while(0)
> +
> +#define freezer_is_on() (0)
> +
> +#endif
>
> So you have your own freezer. Can you still reproduce some failures in
> mainline's freezer? There's one nasty case with vfork() we do not have
> solved...
You've seen the changes I have for process.c already. I'm yet to modify them
to match what did get applied out of our recent discussions, but there's
nothing you haven't seen. This file is just a result of moving some of the
include/linx/sched.h declarations out, so you don't have to recompile
everything that depends on sched.h just because you make a minor change to
(say) a freezer function declaration.
> diff -ruN linux-2.6.15-1/include/linux/kernel.h
> build-2.6.15.1/include/linux/kernel.h ---
> linux-2.6.15-1/include/linux/kernel.h 2006-01-03 15:08:45.000000000 +1000
> +++ build-2.6.15.1/include/linux/kernel.h 2006-01-23 21:38:28.000000000
> +1000 @@ -103,6 +103,8 @@
> __attribute__ ((format (printf, 2, 0)));
> extern int snprintf(char * buf, size_t size, const char * fmt, ...)
> __attribute__ ((format (printf, 3, 4)));
> +extern int snprintf_used(char *buffer, int buffer_size,
> + const char *fmt, ...);
> extern int vsnprintf(char *buf, size_t size, const char *fmt, va_list
> args) __attribute__ ((format (printf, 3, 0)));
> extern int scnprintf(char * buf, size_t size, const char * fmt, ...)
>
>
> Why do you need to modify printf-like functions?!
It's not modified, but a new one. IIRC, the closest one to what I was after
didn't return the info I needed.
> diff -ruN linux-2.6.15-1/include/linux/kthread.h
> build-2.6.15.1/include/linux/kthread.h diff -ruN
> linux-2.6.15-1/include/linux/netlink.h
> build-2.6.15.1/include/linux/netlink.h ---
> linux-2.6.15-1/include/linux/netlink.h 2006-01-03 15:08:45.000000000 +1000
> +++ build-2.6.15.1/include/linux/netlink.h 2006-01-23 21:38:28.000000000
> +1000 @@ -21,6 +21,8 @@
> #define NETLINK_DNRTMSG 14 /* DECnet routing messages */
> #define NETLINK_KOBJECT_UEVENT 15 /* Kernel messages to userspace */
> #define NETLINK_GENERIC 16
> +#define NETLINK_SUSPEND2_USERUI 17 /* For suspend2's userui */
> +#define NETLINK_SUSPEND2_USM 18 /* For suspend2's userui */
>
> #define MAX_LINKS 32
>
>
> Yeh, and this is exactly why uswsusp is superior.
What am I missing?
Oops. The second comment should say storage manager, not userui.
> diff -ruN linux-2.6.15-1/include/linux/sched.h
> build-2.6.15.1/include/linux/sched.h diff -ruN
> linux-2.6.15-1/include/linux/suspend2.h
> build-2.6.15.1/include/linux/suspend2.h +
> +/* Debug sections - if debugging compiled in */
> +enum {
> + SUSPEND_ANY_SECTION,
> + SUSPEND_FREEZER,
> + SUSPEND_EAT_MEMORY,
> + SUSPEND_PAGESETS,
> + SUSPEND_IO,
> + SUSPEND_BMAP,
> + SUSPEND_HEADER,
> + SUSPEND_WRITER,
> + SUSPEND_MEMORY,
> + SUSPEND_EXTENTS,
> + SUSPEND_SPINLOCKS,
> + SUSPEND_MEM_POOL,
> + SUSPEND_RANGE_PARANOIA,
> + SUSPEND_NOSAVE,
> + SUSPEND_INTEGRITY
> +};
> +
> +/* debugging levels. */
> +#define SUSPEND_STATUS 0
> +#define SUSPEND_ERROR 2
> +#define SUSPEND_LOW 3
> +#define SUSPEND_MEDIUM 4
> +#define SUSPEND_HIGH 5
> +#define SUSPEND_VERBOSE 6
> +
> +/* second status register */
> +enum {
> + SUSPEND_REBOOT,
> + SUSPEND_PAUSE,
> + SUSPEND_SLOW,
> + SUSPEND_NOPAGESET2,
> + SUSPEND_LOGALL,
> + SUSPEND_CAN_CANCEL,
> + SUSPEND_KEEP_IMAGE,
> + SUSPEND_FREEZER_TEST,
> + SUSPEND_FREEZER_TEST_SHOWALL,
> + SUSPEND_SINGLESTEP,
> + SUSPEND_PAUSE_NEAR_PAGESET_END,
> + SUSPEND_USE_ACPI_S4,
> + SUSPEND_TEST_FILTER_SPEED,
> + SUSPEND_FREEZE_TIMERS,
> + SUSPEND_DISABLE_SYSDEV_SUPPORT,
> + SUSPEND_VGA_POST,
> + SUSPEND_TEST_BIO,
> + SUSPEND_NO_PAGESET2,
> +};
> +
>
> Not sure what this does, but I surely don't like it.
That's good logic :). They're the flags used internally to record what options
we're in. Could do with a cleanup (thanks!). The 'second status register'
goes way back to when we used a /proc entry with multiple numbers (echo 1 2 3
> config style). Some of those have been unused for ages.
> +extern void __suspend_message(unsigned long section, unsigned long level,
> int log_normally, + const char *fmt, ...);
> +
> +#ifdef CONFIG_PM_DEBUG
> +#define suspend_message(sn, lev, log, fmt, a...) \
> +do { \
> + if (test_debug_state(sn)) \
> + __suspend_message(sn, lev, log, fmt, ##a); \
> +} while(0)
> +#else /* CONFIG_PM_DEBUG */
> +#define suspend_message(sn, lev, log, fmt, a...) \
> +do { \
> + if (lev == 0) \
> + __suspend_message(sn, lev, log, fmt, ##a); \
> +} while(0)
> +#endif /* CONFIG_PM_DEBUG */
> +
> +/* Suspend 2 */
>
> Having your own debugging infrastructure means you are doing something
> wrong.
It was just to provide finer grained debugging, which can be configured while
suspending. You've seen this before.
> +enum {
> + SUSPEND_DISABLED,
> + SUSPEND_RUNNING,
> + SUSPEND_RESUME_DEVICE_OK,
> + SUSPEND_NORESUME_SPECIFIED,
> + SUSPEND_COMMANDLINE_ERROR,
> + SUSPEND_IGNORE_IMAGE,
> + SUSPEND_SANITY_CHECK_PROMPT,
> + SUSPEND_FREEZER_ON,
> + SUSPEND_BLOCK_PAGE_ALLOCATIONS,
> + SUSPEND_USE_MEMORY_POOL,
> + SUSPEND_STAGE2_CONTINUE,
> + SUSPEND_FREEZE_SMP,
> + SUSPEND_PAGESET2_NOT_LOADED,
> + SUSPEND_CONTINUE_REQ,
> + SUSPEND_RESUMED_BEFORE,
> + SUSPEND_RUNNING_INITRD,
> + SUSPEND_RESUME_NOT_DONE,
> + SUSPEND_BOOT_TIME,
> + SUSPEND_NOW_RESUMING,
> + SUSPEND_SLAB_ALLOC_FALLBACK,
> + SUSPEND_IGNORE_LOGLEVEL,
> + SUSPEND_TIMER_FREEZER_ON,
> + SUSPEND_ACT_USED,
> + SUSPEND_DBG_USED,
> + SUSPEND_LVL_USED,
> + SUSPEND_TRYING_TO_RESUME,
> + SUSPEND_FORK_COPYBACK_THREAD,
> + SUSPEND_TRY_RESUME_RD,
> + SUSPEND_IGNORE_ROOTFS,
> +};
>
> What's this? DBG_USED? LVL_USED?
Some more obsolete entries in there. Dbg_used and lvl_used let me change the
debugging from the command line when trying to resume, and these flags were
used so that the settings in the image header didn't overwrite the values
given on the command line. I doubt they're ever used nowadays, so could go
too. Will be out in the next release.
> diff -ruN linux-2.6.15-1/include/linux/suspend.h
> build-2.6.15.1/include/linux/suspend.h diff -ruN
> linux-2.6.15-1/include/linux/workqueue.h
> build-2.6.15.1/include/linux/workqueue.h diff -ruN
> linux-2.6.15-1/init/do_mounts.c build-2.6.15.1/init/do_mounts.c diff -ruN
> linux-2.6.15-1/init/do_mounts_initrd.c
> build-2.6.15.1/init/do_mounts_initrd.c ---
> linux-2.6.15-1/init/do_mounts_initrd.c 2006-01-03 15:08:48.000000000 +1000
> +++ build-2.6.15.1/init/do_mounts_initrd.c 2006-01-23 21:38:28.000000000
> +1000 @@ -7,6 +7,7 @@
> #include <linux/romfs_fs.h>
> #include <linux/initrd.h>
> #include <linux/sched.h>
> +#include <linux/suspend.h>
>
> #include "do_mounts.h"
>
> @@ -58,10 +59,16 @@
>
> pid = kernel_thread(do_linuxrc, "/linuxrc", SIGCHLD);
> if (pid > 0) {
> - while (pid != sys_wait4(-1, NULL, 0, NULL))
> + while (pid != sys_wait4(-1, NULL, 0, NULL)) {
> yield();
> + try_to_freeze();
> + }
> }
>
> Not run_todo_list? Do we want this in mainline?
:) Christoph's patches made try_to_freeze() == run_todo_list, so it didn't
matter. I think you will want it if you support starting a resume from an
initrd and freeze processes before the atomic restore.
> diff -ruN linux-2.6.15-1/init/main.c build-2.6.15.1/init/main.c
> diff -ruN linux-2.6.15-1/kernel/audit.c build-2.6.15.1/kernel/audit.c
> diff -ruN linux-2.6.15-1/kernel/fork.c build-2.6.15.1/kernel/fork.c
> --- linux-2.6.15-1/kernel/fork.c 2006-01-03 15:08:48.000000000 +1000
> +++ build-2.6.15.1/kernel/fork.c 2006-01-23 21:38:28.000000000 +1000
> @@ -165,7 +166,13 @@
> if (!tsk)
> return NULL;
>
> - ti = alloc_thread_info(tsk);
> + if (test_suspend_state(SUSPEND_FORK_COPYBACK_THREAD)) {
> + extern void * suspend2_get_nonconflicting_pages(int);
> + ti = suspend2_get_nonconflicting_pages(get_order(THREAD_SIZE));
> + printk("Starting a copyback thread %p\n", ti);
> + } else
> + ti = alloc_thread_info(tsk);
> +
> if (!ti) {
> free_task_struct(tsk);
> return NULL;
>
> With code like this (in fork!) how can you claim it is not complex?
> What does copyback do, anyway?
We're just making sure here that the stack page for the thread that gets
started is in a page that won't be overwritten during the atomic restore.
With that done, using stack in the atomic restore routine is safe.
> diff -ruN linux-2.6.15-1/kernel/kmod.c build-2.6.15.1/kernel/kmod.c
> diff -ruN linux-2.6.15-1/kernel/kthread.c build-2.6.15.1/kernel/kthread.c
> diff -ruN linux-2.6.15-1/kernel/power/atomic_copy.c
> build-2.6.15.1/kernel/power/atomic_copy.c ---
> linux-2.6.15-1/kernel/power/atomic_copy.c 1970-01-01 10:00:00.000000000
> +1000 +++ build-2.6.15.1/kernel/power/atomic_copy.c 2006-01-23
> 21:38:28.000000000 +1000 @@ -0,0 +1,473 @@
> +/*
> + */
> +
> +#include <linux/suspend.h>
> +#include <linux/highmem.h>
> +#include <linux/kthread.h>
> +#include <asm/setup.h>
> +#include <asm/param.h>
> +#include <asm/thread_info.h>
> +#include "suspend2_common.h"
> +#include "io.h"
> +#include "power_off.h"
> +#include "version.h"
> +#include "ui.h"
> +#include "plugins.h"
> +#include "atomic_copy.h"
> +#include "suspend2.h"
> +#include "checksum.h"
> +#include "pageflags.h"
> +#include "debug_pagealloc.h"
> +#include "storage.h"
> +
> +#include <asm/suspend2.h>
> +
> +volatile static int state1 __nosavedata = 0;
> +volatile static int state2 __nosavedata = 0;
> +volatile static int state3 __nosavedata = 0;
> +volatile static int io_speed_save[2][2] __nosavedata;
> +
>
> Heh, nice... volatile probably means you got the locking wrong, and no
> it is not nice to name variables like this.
What do you think I'm doing here? Actually volatile is just one of those
cleanups that never got done by a user who didn't know they weren't needed to
begin with :)
> Why can't you just use existing code for atomic copy?
>
> (~400 lines of duplicated code skipped)
As mentioned above, different data structures; the code isn't duplicated.
> diff -ruN linux-2.6.15-1/kernel/power/atomic_copy.h
> build-2.6.15.1/kernel/power/atomic_copy.h diff -ruN
> linux-2.6.15-1/kernel/power/block_io.h
> build-2.6.15.1/kernel/power/block_io.h ---
> linux-2.6.15-1/kernel/power/block_io.h 1970-01-01 10:00:00.000000000 +1000
> +++ build-2.6.15.1/kernel/power/block_io.h 2006-01-23 21:38:28.000000000
> +1000 @@ -0,0 +1,76 @@
> +/*
> + * block_io.h
> + *
> + * Copyright 2004-2005 Nigel Cunningham <[email protected]>
> + *
> + * Distributed under GPLv2.
> + *
> + * This file contains declarations for functions exported from
> + * block_io.c, which contains low level io functions.
> + */
> +
> +#include <linux/buffer_head.h>
> +#include "extent.h"
> +
> +/*
> + * submit_params
> + *
> + * The structure we use for tracking submitted I/O.
> + */
> +struct submit_params {
> + swp_entry_t swap_address;
> + struct page *page;
> + struct block_device *dev;
> + sector_t block[MAX_BUF_PER_PAGE];
> + int readahead_index;
> + struct submit_params *next;
> + int printme;
> +};
> +
> +struct suspend2_bdev_info {
> + struct block_device *bdev;
> + dev_t dev_t;
> + int bmap_shift;
> + int blocks_per_page;
> +};
> +
> +/*
> + * Our exported interface so the swapwriter and filewriter don't
> + * need these functions duplicated.
> + */
> +struct suspend_bio_ops {
> + int (*submit_io) (int rw,
> + struct submit_params *submit_info, int syncio);
> + int (*bdev_page_io) (int rw, struct block_device *bdev, long pos,
> + struct page *page);
> + int (*rw_page) (int rw, struct page *page, int readahead_index,
> + int sync);
> + void (*wait_on_readahead) (int readahead_index);
> + void (*check_io_stats) (void);
> + void (*reset_io_stats) (void);
> + void (*finish_all_io) (void);
> + int (*prepare_readahead) (int index);
> + void (*cleanup_readahead) (int index);
> + struct page ** readahead_pages;
> + int (*readahead_ready) (int readahead_index);
> + int *need_extra_next;
> + int (*forward_one_page) (void);
> + void (*set_devinfo) (struct suspend2_bdev_info *info);
> + int (*read_init) (int stream_number);
> + int (*read_chunk) (struct page *buffer_page, int sync);
> + int (*read_cleanup) (void);
> + int (*write_init) (int stream_number);
> + int (*write_chunk) (struct page *buffer_page);
> + int (*write_cleanup) (void);
> + int (*read_header_chunk) (char *buffer, int buffer_size);
> + int (*write_header_chunk) (char *buffer, int buffer_size);
> + int (*write_header_chunk_finish) (void);
> +};
>
> So you have your own disk operations... Nothing like that is needed
> with uswsusp.
They're just the routines shared by the writers (which shoudl really be called
something different now that I've moved all the real work to this file :>). I
think I could further clean this up, removing the header specific routines.
And the point to it all is doing the async I/O and readahead, given just
lists of blocks on devices and (via these routines) the pages to write. If
uswsusp supported swapfiles and ordinary files, it would have something like
this.
> diff -ruN linux-2.6.15-1/kernel/power/checksum.h
> build-2.6.15.1/kernel/power/checksum.h ---
> linux-2.6.15-1/kernel/power/checksum.h 1970-01-01 10:00:00.000000000 +1000
> +++ build-2.6.15.1/kernel/power/checksum.h 2006-01-23 21:38:28.000000000
> +1000 @@ -0,0 +1,11 @@
> +#ifdef CONFIG_SUSPEND2_CHECKSUMS
> +extern void suspend2_verify_checksums(void);
> +extern void suspend2_checksum_calculate_checksums(void);
> +extern void suspend2_checksum_print_differences(void);
> +extern int suspend2_allocate_checksum_pages(void);
> +#else
> +static inline void suspend2_verify_checksums(void) { };
> +static inline void suspend2_checksum_calculate_checksums(void) { };
> +static inline void suspend2_checksum_print_differences(void) { };
> +static inline int suspend2_allocate_checksum_pages(void) { return 0; };
> +#endif
>
> ...and checksums can happily live in userspace.
Yes. I should really clean this up and make it just another (optional) item in
the pipeline.
> diff -ruN linux-2.6.15-1/kernel/power/compression.c
> build-2.6.15.1/kernel/power/compression.c ---
> linux-2.6.15-1/kernel/power/compression.c 1970-01-01 10:00:00.000000000
> +1000 +++ build-2.6.15.1/kernel/power/compression.c 2006-01-23
> 21:38:28.000000000 +1000 @@ -0,0 +1,638 @@
> +/*
> + * kernel/power/suspend2_core/compression.c
>
> Wrong filename.
Thanks. Another cleanup missed.
> + * Copyright (C) 2003-2005 Nigel Cunningham <[email protected]>
> + *
> + * This file is released under the GPLv2.
> + *
> + * This file contains data compression routines for suspend,
> + * using LZH compression.
>
> LZF?
Should be cryptoapi now.
> Snipped 600 lines of code that can happily live in userspace.
You can use cryptoapi from userspace?
> diff -ruN linux-2.6.15-1/kernel/power/debug_pagealloc.c
> build-2.6.15.1/kernel/power/debug_pagealloc.c ---
> linux-2.6.15-1/kernel/power/debug_pagealloc.c 1970-01-01 10:00:00.000000000
> +1000 +++ build-2.6.15.1/kernel/power/debug_pagealloc.c 2006-01-23
> 21:38:28.000000000 +1000 @@ -0,0 +1,111 @@
> +#include <linux/mm.h>
> +#ifdef CONFIG_DEBUG_PAGEALLOC
> +#include <linux/page-flags.h>
> +#include <asm/pgtable.h>
> +
> +#include "pageflags.h"
> +#include "suspend2.h"
> +#include "pagedir.h"
>
>
> What is this code doing?
Support for CONFIG_DEBUG_PAGEALLOC. Rarely used and I think it's broken. (I
should check).
> diff -ruN linux-2.6.15-1/kernel/power/debug_pagealloc.h
> build-2.6.15.1/kernel/power/debug_pagealloc.h diff -ruN
> linux-2.6.15-1/kernel/power/disk.c build-2.6.15.1/kernel/power/disk.c diff
> -ruN linux-2.6.15-1/kernel/power/encryption.c
> build-2.6.15.1/kernel/power/encryption.c ---
> linux-2.6.15-1/kernel/power/encryption.c 1970-01-01 10:00:00.000000000
> +1000 +++ build-2.6.15.1/kernel/power/encryption.c 2006-01-23
> 21:38:28.000000000 +1000 @@ -0,0 +1,597 @@
> +/*
> + * kernel/power/suspend2_core/encryption.c
> + *
> + * Copyright (C) 2003-2005 Nigel Cunningham <[email protected]>
> + *
> + * This file is released under the GPLv2.
> + *
> + * This file contains data encryption routines for suspend,
> + * using cryptoapi transforms.
> + *
> + * ToDo:
> + * - Apply min/max_keysize the cipher changes.
> + * - Test.
> + */
>
> Snipped 550 lines of code that can happily live in userspace.
(if cryptoapi can be used from there).
> diff -ruN linux-2.6.15-1/kernel/power/extent.c
> build-2.6.15.1/kernel/power/extent.c ---
> linux-2.6.15-1/kernel/power/extent.c 1970-01-01 10:00:00.000000000 +1000
> +++ build-2.6.15.1/kernel/power/extent.c 2006-01-23 21:38:28.000000000
> +1000 @@ -0,0 +1,247 @@
> +/* kernel/power/suspend2_core/extent.c
> + *
> + * (C) 2003-2005 Nigel Cunningham <[email protected]>
> + *
> + * Distributed under GPLv2.
> + *
> + * These functions encapsulate the manipulation of storage metadata. For
> + * pageflags, we use dynamically allocated bitmaps.
> + */
> +
>
> I do not know why you want to use extents; existing code seems to work
> well enough. Do you get .01% speedup or what?
They're used for storing the lists of blocks on each dev in which we store the
image. It has nothing to do with a speedup, but rather efficient storage of
the metadata.
> diff -ruN linux-2.6.15-1/kernel/power/extent.h
> build-2.6.15.1/kernel/power/extent.h +
> +#define extent_state_eof(state) ((state)->num_chains <
> (state)->current_chain) +
> +#define extent_for_each(extent_chain, extentpointer, value) \
> +if ((extent_chain)->first) \
> + for ((extentpointer) = (extent_chain)->first, (value) = \
> + (extentpointer)->minimum; \
> + ((extentpointer) && ((extentpointer)->next || (value) <= \
> + (extentpointer)->maximum)); \
> + (((value) == (extentpointer)->maximum) ? \
> + ((extentpointer) = (extentpointer)->next, (value) = \
> + ((extentpointer) ? (extentpointer)->minimum : 0)) : \
> + (value)++))
> +
> +/*
> + * When using compression and expected_compression > 0,
> + * we allocate fewer swap entries, so GET_EXTENT_NEXT can
> + * validly run out of data to return.
> + */
> +#define GET_EXTENT_NEXT(currentextent, currentval) \
> +{ \
> + if (currentextent) { \
> + if ((currentval) == (currentextent)->maximum) { \
> + if ((currentextent)->next) { \
> + (currentextent) = (currentextent)->next; \
> + (currentval) = (currentextent)->minimum; \
> + } else { \
> + (currentextent) = NULL; \
> + (currentval) = 0; \
> + } \
> + } else \
> + currentval++; \
> + } \
> +}
>
> Not nice at all.
You have a nicer equivalent? I thought it was quite readable. Anyway, since it
appears that it's now only used in one place, I can clean it up :) Done.
> diff -ruN linux-2.6.15-1/kernel/power/io.c build-2.6.15.1/kernel/power/io.c
> --- linux-2.6.15-1/kernel/power/io.c 1970-01-01 10:00:00.000000000 +1000
> +++ build-2.6.15.1/kernel/power/io.c 2006-01-23 21:38:28.000000000 +1000
> @@ -0,0 +1,1025 @@
> +/*
> + * kernel/power/io.c
> + *
> + * Copyright (C) 1998-2001 Gabor Kuti <[email protected]>
> + * Copyright (C) 1998,2001,2002 Pavel Machek <[email protected]>
> + * Copyright (C) 2002-2003 Florent Chabaud <[email protected]>
> + * Copyright (C) 2002-2005 Nigel Cunningham <[email protected]>
> + *
> + * This file is released under the GPLv2.
> + *
> + * It contains high level IO routines for suspending.
> + *
> + */
>
> Snipped 1000 lines that can happily live in userspace. Yes, I have
> similar (but way simpler) code in kernel just now. Notice I want to
> remove it.
Simpler because it's not providing the same functionality.
> diff -ruN linux-2.6.15-1/kernel/power/io.h build-2.6.15.1/kernel/power/io.h
> diff -ruN linux-2.6.15-1/kernel/power/Kconfig
> build-2.6.15.1/kernel/power/Kconfig ---
> linux-2.6.15-1/kernel/power/Kconfig 2006-01-03 15:08:48.000000000 +1000 +++
> build-2.6.15.1/kernel/power/Kconfig 2006-01-23 21:38:28.000000000 +1000 @@
> -98,3 +98,76 @@
> bool
> depends on HOTPLUG_CPU && X86 && PM
> default y
> +
> +config SUSPEND_DEBUG_PAGEALLOC
> + bool
> + depends on DEBUG_PAGEALLOC && (SOFTWARE_SUSPEND || SUSPEND2)
> + default y
> +
> +config SUSPEND2_CRYPTO
> + bool
> + depends on SUSPEND2 && CRYPTO
> + default y
> +
> +menuconfig SUSPEND2
> + bool "Suspend2"
> + select DYN_PAGEFLAGS
> + depends on PM
> + select HOTPLUG_CPU if SMP
> + ---help---
> + Suspend2 is the 'new and improved' suspend support.
> +
> + See the Suspend2 home page (suspend2.net)
> + for FAQs, HOWTOs and other documentation.
> +
> + comment 'Image Storage (you need at least one writer)'
> + depends on SUSPEND2
> +
> + config SUSPEND2_FILEWRITER
> + bool ' File Writer'
> + depends on SUSPEND2
> + ---help---
> + This option enables support for storing an image in a
> + simple file. This should be possible, but we're still
> + testing it.
> +
> + config SUSPEND2_SWAPWRITER
> + bool ' Swap Writer'
> + depends on SUSPEND2
> + select SWAP
> + ---help---
> + This option enables support for storing an image in your
> + swap space.
> +
> + comment 'General Options'
> + depends on SUSPEND2
> +
> + config SUSPEND2_DEFAULT_RESUME2
> + string ' Default resume device name'
> + depends on SUSPEND2
> + ---help---
> + You normally need to add a resume2= parameter to your lilo.conf or
> + equivalent. With this option properly set, the kernel has a value
> + to default. No damage will be done if the value is invalid.
> +
> + config SUSPEND2_CHECKSUMMING
> + bool ' Checksum images - developer option (SLOW!)'
> + depends on PM_DEBUG && SUSPEND2
> + ---help---
> + This option implements checksumming of images. It is not designed
> + for everyone to use, but as a development tool.
> +
> + config SUSPEND2_KEEP_IMAGE
> + bool ' Allow Keep Image Mode'
> + depends on SUSPEND2
> + ---help---
> + This option allows you to keep and image and reuse it. It is intended
> + __ONLY__ for use with systems where all filesystems are mounted read-
> + only (kiosks, for example). To use it, compile this option in and boot
> + normally. Set the KEEP_IMAGE flag in /proc/suspend2 and suspend.
> + When you resume, the image will not be removed. You will be unable to
> turn + off swap partitions (assuming you are using the swap writer), but
> future + suspends simply do a power-down. The image can be updated using
> the + kernel command line parameter suspend_act= to turn off the keep
> image + bit. Keep image mode is a little less user friendly on purpose -
> it + should not be used without thought!
>
> All this configuration can and should be done in userspace. That's 70
> lines.
>
> diff -ruN linux-2.6.15-1/kernel/power/main.c
> build-2.6.15.1/kernel/power/main.c diff -ruN
> linux-2.6.15-1/kernel/power/Makefile build-2.6.15.1/kernel/power/Makefile
> diff -ruN linux-2.6.15-1/kernel/power/netlink.c
> build-2.6.15.1/kernel/power/netlink.c ---
> linux-2.6.15-1/kernel/power/netlink.c 1970-01-01 10:00:00.000000000 +1000
> +++ build-2.6.15.1/kernel/power/netlink.c 2006-01-23 21:38:28.000000000
> +1000 @@ -0,0 +1,365 @@
> +/*
> + * netlink.c
> + *
> + * Functions for communicating with a userspace helper via netlink.
> + */
>
> With Rafael's solution, you don't need to inform userspace of your
> progress -- because userspace is controlling the suspend. Snip 300
> unneeded lines.
True. There you have a point.
> +static int suspend2_nl_gen_rcv_msg(struct user_helper_data *uhd,
> + struct sk_buff *skb, struct nlmsghdr *nlh)
> +{
> + int type;
> + int *data;
> + int err;
> +
> + /* Let the more specific handler go first. It returns
> + * 1 for valid messages that it doesn't know. */
> + if ((err = uhd->rcv_msg(skb, nlh)) != 1)
> + return err;
>
>
> ...some of them pretty cryptic.
True. Will add to to do list :)
> +static int launch_userpace_program(struct user_helper_data *uhd)
> +{
> + int retval;
> + static char *envp[] = {
> + "HOME=/",
> + "TERM=linux",
> + "PATH=/sbin:/usr/sbin:/bin:/usr/bin",
> + NULL };
> + static char *argv[] = { NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL };
> + char *channel = kmalloc(6, GFP_KERNEL);
> + int arg = 0, size;
> + char test_read[255];
> + char *orig_posn = uhd->program;
> +
> + if (!strlen(orig_posn))
> + return 1;
> +
> + while (arg < 7) {
> + sscanf(orig_posn, "%s", test_read);
> + size = strlen(test_read);
> + if (!(size))
> + break;
> + argv[arg] = kmalloc(size + 1, GFP_ATOMIC);
> + strcpy(argv[arg], test_read);
> + orig_posn += size + 1;
> + *test_read = 0;
> + arg++;
> + }
> +
> + sprintf(channel, "-c%d", uhd->netlink_id);
> + argv[arg] = channel;
> +
> + retval = call_usermodehelper(argv[0], argv, envp, 0);
>
> It is really better if userspace calls you...
Well, this way, we don't care if userspace doesn't come to the party. We can
still suspend and resume without it.
> diff -ruN linux-2.6.15-1/kernel/power/netlink.h
> build-2.6.15.1/kernel/power/netlink.h diff -ruN
> linux-2.6.15-1/kernel/power/pagedir.c build-2.6.15.1/kernel/power/pagedir.c
> --- linux-2.6.15-1/kernel/power/pagedir.c 1970-01-01 10:00:00.000000000
> +1000 +++ build-2.6.15.1/kernel/power/pagedir.c 2006-01-23
> 21:38:28.000000000 +1000 @@ -0,0 +1,370 @@
> +/*
> + * kernel/power/pagedir.c
> + *
> + * Copyright (C) 1998-2001 Gabor Kuti <[email protected]>
> + * Copyright (C) 1998,2001,2002 Pavel Machek <[email protected]>
> + * Copyright (C) 2002-2003 Florent Chabaud <[email protected]>
> + * Copyright (C) 2002-2005 Nigel Cunningham <[email protected]>
> + *
> + * This file is released under the GPLv2.
> + *
> + * Routines for handling pagesets.
> + * Note that pbes aren't actually stored as such. They're stored as
> + * bitmaps and extents.
> + */
>
> You should be able to use existing snapshotting...
If I get rid of support for storing a two sets of pages.
> +#include <linux/suspend.h>
> +#include <linux/highmem.h>
> +#include <linux/bootmem.h>
> +#include <linux/hardirq.h>
> +
> +#include "pageflags.h"
> +#include "ui.h"
> +#include "pagedir.h"
> +
> +int extra_pagedir_pages_allocated = 0;
>
> Do not zero-initialize static variables.
Ta. Hadn't seen that.
> diff -ruN linux-2.6.15-1/kernel/power/pagedir.h
> build-2.6.15.1/kernel/power/pagedir.h diff -ruN
> linux-2.6.15-1/kernel/power/pageflags.c
> build-2.6.15.1/kernel/power/pageflags.c ---
> linux-2.6.15-1/kernel/power/pageflags.c 1970-01-01 10:00:00.000000000 +1000
> +++ build-2.6.15.1/kernel/power/pageflags.c 2006-01-23 21:38:28.000000000
> +1000 @@ -0,0 +1,139 @@
> +/*
> + * kernel/power/suspend2_core/pageflags.c
>
> Wrong name.
Ta.
> + * Copyright (C) 2004-2005 Nigel Cunningham <[email protected]>
> + *
> + * This file is released under the GPLv2.
> + *
> + * Routines for dynamically allocating and releasing bitmaps
> + * used as pseudo-pageflags.
> + *
> + * Arrays are not contiguous. The first sizeof(void *) bytes are
> + * the pointer to the next page in the bitmap. This allows us to
> + * 1) work under low memory conditions where order 0 might be all
> + * that's available
> + * 2) save the pages at suspend time, reload and relocate them as
> + * necessary at resume time without breaking anything (cf
> + * extent pages).
> + */
>
> Why do you need this?
Ooh. That comment is old :). This is the suspend2 specific part of the
pageflags code above. It allows us to serialise the flags and relocate parts
of the bitmap that will be overwritten when restoring the original kernel
data.
> diff -ruN linux-2.6.15-1/kernel/power/pageflags.h
> build-2.6.15.1/kernel/power/pageflags.h diff -ruN
> linux-2.6.15-1/kernel/power/plugins.c build-2.6.15.1/kernel/power/plugins.c
> --- linux-2.6.15-1/kernel/power/plugins.c 1970-01-01 10:00:00.000000000
> +1000 +++ build-2.6.15.1/kernel/power/plugins.c 2006-01-23
> 21:38:28.000000000 +1000 @@ -0,0 +1,312 @@
> +/*
> + * kernel/power/plugins.c
> + *
> + * Copyright (C) 2004-2005 Nigel Cunningham <[email protected]>
> + *
> + */
>
> Oh, my favourite.. These should really be in userspace. 300 lines +
> 180 lines in header.
Glad you like it :).
> diff -ruN linux-2.6.15-1/kernel/power/plugins.h
> build-2.6.15.1/kernel/power/plugins.h diff -ruN
> linux-2.6.15-1/kernel/power/power.h build-2.6.15.1/kernel/power/power.h
>
>
> /* References to section boundaries */
> -extern const void __nosave_begin, __nosave_end;
> +//extern const void __nosave_begin, __nosave_end;
>
> Delete it if you want it gone...
Done. Ta.
> diff -ruN linux-2.6.15-1/kernel/power/power_off.c
> build-2.6.15.1/kernel/power/power_off.c ---
> linux-2.6.15-1/kernel/power/power_off.c 1970-01-01 10:00:00.000000000 +1000
> +++ build-2.6.15.1/kernel/power/power_off.c 2006-01-23 21:38:28.000000000
> +1000 @@ -0,0 +1,79 @@
> +/*
> + * kernel/power/suspend2_core/power_off.c
>
> Wrong name.
Ta.
> +void suspend_power_down(void)
> +{
> + if (test_action_state(SUSPEND_REBOOT)) {
> + suspend2_prepare_status(DONT_CLEAR_BAR, "Ready to reboot.");
> + kernel_restart(NULL);
> + }
>
> And we do not want UI code in kernel.
This is telling the UI what to do (as opposed to userspace telling the kernel
what to do ;-)).
> diff -ruN linux-2.6.15-1/kernel/power/power_off.h
> build-2.6.15.1/kernel/power/power_off.h diff -ruN
> linux-2.6.15-1/kernel/power/prepare_image.c
> build-2.6.15.1/kernel/power/prepare_image.c ---
> linux-2.6.15-1/kernel/power/prepare_image.c 1970-01-01 10:00:00.000000000
> +1000 +++ build-2.6.15.1/kernel/power/prepare_image.c 2006-01-23
> 21:38:28.000000000 +1000 @@ -0,0 +1,753 @@
> +/*
> + * kernel/power/prepare_image.c
> + *
> + * Copyright (C) 2003-2005 Nigel Cunningham <[email protected]>
> + *
> + * This file is released under the GPLv2.
> + *
> + * We need to eat memory until we can:
> + * 1. Perform the save without changing anything (RAM_NEEDED < max_pfn)
> + * 2. Fit it all in available space (active_writer->available_space() >=
> + * storage_needed())
> + * 3. Reload the pagedir and pageset1 to places that don't collide with
> their + * final destinations, not knowing to what extent the resumed
> kernel will + * overlap with the one loaded at boot time. I think the
> resumed kernel + * should overlap completely, but I don't want to rely
> on this as it is + * an unproven assumption. We therefore assume there
> will be no overlap at + * all (worse case).
> + * 4. Meet the user's requested limit (if any) on the size of the image.
> + * The limit is in MB, so pages/256 (assuming 4K pages).
> + *
> + */
>
> There's existing code in kernel to do this, no?
No. It doesn't support letting the user configure the limit they want (without
requiring a recompile) and it doesn't support storing a full image of memory.
It is cleaner and simpler, but I'm not sure it would work as reliably under
stress. I know I have cleanups to do here. There are surely still leftovers
from when we used that memory pool and I know I currently have a bug to chase
down.
> diff -ruN linux-2.6.15-1/kernel/power/prepare_image.h
> build-2.6.15.1/kernel/power/prepare_image.h diff -ruN
> linux-2.6.15-1/kernel/power/proc.c build-2.6.15.1/kernel/power/proc.c ---
> linux-2.6.15-1/kernel/power/proc.c 1970-01-01 10:00:00.000000000 +1000 +++
> build-2.6.15.1/kernel/power/proc.c 2006-01-23 21:38:28.000000000 +1000 @@
> -0,0 +1,305 @@
> +/*
> + * /kernel/power/proc.c
>
> Spurious slash?
Ta.
> + * Copyright (C) 2002-2005 Nigel Cunningham <[email protected]>
> + *
> + * This file is released under the GPLv2.
> + *
> + * This file contains support for proc entries for tuning Suspend2.
> + *
> + * We have a generic handler that deals with the most common cases, and
> + * hooks for special handlers to use.
> + */
>
> Well, we probably do not want more junk in /proc. And this would not
> be neccessary if (surprise) userspace controlled suspend. 300 lines
> unneeeded, and 70 lines in header.
:) But you would need more ioctls.
> diff -ruN linux-2.6.15-1/kernel/power/process.c
> build-2.6.15.1/kernel/power/process.c diff -ruN
> linux-2.6.15-1/kernel/power/proc.h build-2.6.15.1/kernel/power/proc.h diff
> -ruN linux-2.6.15-1/kernel/power/snapshot.c
> build-2.6.15.1/kernel/power/snapshot.c diff -ruN
> linux-2.6.15-1/kernel/power/storage.c build-2.6.15.1/kernel/power/storage.c
> --- linux-2.6.15-1/kernel/power/storage.c 1970-01-01 10:00:00.000000000
> +1000 +++ build-2.6.15.1/kernel/power/storage.c 2006-01-23
> 21:38:28.000000000 +1000 @@ -0,0 +1,323 @@
> +/*
> + * kernel/power/storage.c
> + *
> + * Copyright (C) 2005 Nigel Cunningham <[email protected]>
> + *
> + * This file is released under the GPLv2.
> + *
> + * Routines for talking to a userspace program that manages storage.
> + *
> + * The kernel side:
> + * - starts the userspace program;
> + * - sends messages telling it when to open and close the connection;
> + * - tells it when to quit;
> + *
> + * The user space side:
> + * - passes messages regarding status;
>
> Yep, if you do it all in userspace, this vanishes. 340 lines down.
And you gain? Let's try not to be too biased :).
> diff -ruN linux-2.6.15-1/kernel/power/storage.h
> build-2.6.15.1/kernel/power/storage.h diff -ruN
> linux-2.6.15-1/kernel/power/suspend2_common.h
> build-2.6.15.1/kernel/power/suspend2_common.h diff -ruN
> linux-2.6.15-1/kernel/power/suspend2.h
> build-2.6.15.1/kernel/power/suspend2.h ---
> linux-2.6.15-1/kernel/power/suspend2.h 1970-01-01 10:00:00.000000000 +1000
> +++ build-2.6.15.1/kernel/power/suspend2.h 2006-01-23 21:38:28.000000000
> +1000 +
> +#define KB(x) ((x) << (PAGE_SHIFT - 10))
> +#define MB(x) ((x) >> (20 - PAGE_SHIFT))
> +
>
> Eh, nice macros... this should be done for whole kernel or not t all.
Long time since I thought about them. Maybe someone has put the same thing
elsewhere in the mean time. Todo list.
> diff -ruN linux-2.6.15-1/kernel/power/suspend_block_io.c
> build-2.6.15.1/kernel/power/suspend_block_io.c ---
> linux-2.6.15-1/kernel/power/suspend_block_io.c 1970-01-01
> 10:00:00.000000000 +1000 +++
> build-2.6.15.1/kernel/power/suspend_block_io.c 2006-01-23
> 21:38:28.000000000 +1000 @@ -0,0 +1,1086 @@
> +/*
> + * block_io.c
>
> Wrong name.
Ta.
> + * Copyright 2004-2005 Nigel Cunningham <[email protected]>
> + *
> + * Distributed under GPLv2.
> + *
> + * This file contains block io functions for suspend2. These are
> + * used by the swapwriter and it is planned that they will also
> + * be used by the NFSwriter.
> + *
> + */
>
> 1080 lines that are not neccessary in uswsusp case, because we can
> simply use existing read/write routines.
But only if you stick to only supporting writing to a single swap parttiion.
> diff -ruN linux-2.6.15-1/kernel/power/suspend.c
> build-2.6.15.1/kernel/power/suspend.c ---
> linux-2.6.15-1/kernel/power/suspend.c 1970-01-01 10:00:00.000000000 +1000
> +++ build-2.6.15.1/kernel/power/suspend.c 2006-01-23 21:38:28.000000000
> +1000 @@ -0,0 +1,1133 @@
> +/*
> + * kernel/power/suspend2.c
>
> Name?
Ta.
> +/* Compression ratio */
> +__nosavedata unsigned long bytes_in = 0, bytes_out = 0;
> +
>
> Should not compression live in its own plugin?
Another missed cleanup. The tricky bit here is that I don't know the final
number of bytes sent to and output by the compressor until the end of writing
the image, so to get the stats back at the end of resuming, it needs to be
stored in the image header and then preserved during the atomic restore. I
suppose re-reading the header at the end of resuming might be another idea.
Will think on this some more.
> diff -ruN linux-2.6.15-1/kernel/power/suspend_checksums.c
> build-2.6.15.1/kernel/power/suspend_checksums.c ---
> linux-2.6.15-1/kernel/power/suspend_checksums.c 1970-01-01
> 10:00:00.000000000 +1000 +++
> build-2.6.15.1/kernel/power/suspend_checksums.c 2006-01-23
> 21:38:28.000000000 +1000 @@ -0,0 +1,509 @@
>
> Checksumming can live in userspace, 500 lines down.
>
> diff -ruN linux-2.6.15-1/kernel/power/suspend_file.c
> build-2.6.15.1/kernel/power/suspend_file.c ---
> linux-2.6.15-1/kernel/power/suspend_file.c 1970-01-01 10:00:00.000000000
> +1000 +++ build-2.6.15.1/kernel/power/suspend_file.c 2006-01-23
> 21:38:28.000000000 +1000 @@ -0,0 +1,1077 @@
> +/*
> + * Filewriter.c
>
> Name?
Ta.
> Can happily live in userspace (using bmap), 1070 lines down.
How would you do the I/O once you'd bmapped? I thought you rejected bios.
> diff -ruN linux-2.6.15-1/kernel/power/suspend.h
> build-2.6.15.1/kernel/power/suspend.h diff -ruN
> linux-2.6.15-1/kernel/power/suspend_swap.c
> build-2.6.15.1/kernel/power/suspend_swap.c ---
> linux-2.6.15-1/kernel/power/suspend_swap.c 1970-01-01 10:00:00.000000000
> +1000 +++ build-2.6.15.1/kernel/power/suspend_swap.c 2006-01-23
> 21:38:28.000000000 +1000 @@ -0,0 +1,1213 @@
> +/*
> + * Swapwriter.c
> + *
> + * Copyright 2004-2005 Nigel Cunningham <[email protected]>
> + *
> + * Distributed under GPLv2.
> + *
> + * This file encapsulates functions for usage of swap space as a
> + * backing store.
> + */
>
> Should be possible to put into userspace, 1200 lines.
>
> diff -ruN linux-2.6.15-1/kernel/power/swsusp.c
> build-2.6.15.1/kernel/power/swsusp.c diff -ruN
> linux-2.6.15-1/kernel/power/swsusp.h build-2.6.15.1/kernel/power/swsusp.h
> diff -ruN linux-2.6.15-1/kernel/power/ui.c build-2.6.15.1/kernel/power/ui.c
> --- linux-2.6.15-1/kernel/power/ui.c 1970-01-01 10:00:00.000000000 +1000
> +++ build-2.6.15.1/kernel/power/ui.c 2006-01-23 21:38:28.000000000 +1000 @@
> -0,0 +1,853 @@
> +/*
> + * kernel/power/ui.c
> + *
> + * Copyright (C) 1998-2001 Gabor Kuti <[email protected]>
> + * Copyright (C) 1998,2001,2002 Pavel Machek <[email protected]>
> + * Copyright (C) 2002-2003 Florent Chabaud <[email protected]>
> + * Copyright (C) 2002-2005 Nigel Cunningham <[email protected]>
> + *
> + * This file is released under the GPLv2.
> + *
> + * Routines for Suspend2's user interface.
> + *
> + * The user interface code talks to a userspace program via a
> + * netlink socket.
> + *
> + * The kernel side:
> + * - starts the userui program;
> + * - sends text messages and progress bar status;
> + *
> + * The user space side:
> + * - passes messages regarding user requests (abort, toggle reboot etc)
> + *
> + */
>
> Userinterface in kernel. Great. Fortunately Rafael's code allows this
> 850 lines not to be needed.
>
> +char suspend_wait_for_keypress(int timeout)
> +{
> + int fd;
> + char key = '\0';
> + struct termios t, t_backup;
> +
> + if (ui_helper_data.pid != -1) {
> + wait_for_key_via_userui();
> + key = ' ';
> + goto out;
> + }
> +
> + /* We should be guaranteed /dev/console exists after populate_rootfs() in
> + * init/main.c
> + */
> + if ((fd = sys_open("/dev/console", O_RDONLY, 0)) < 0) {
> + printk("Couldn't open /dev/console.\n");
> + goto out;
> + }
>
> ...and you still do user interface in kernel, despite having userland
> helper.
printks, yes. You don't do any printks?
> +/* abort_suspend
> + *
> + * Description: Begin to abort a cycle. If this wasn't at the user's
> request + * (and we're displaying output), tell the user why and wait for
> + * them to acknowledge the message.
> + * Arguments: A parameterised string (imagine this is printk) to display,
> + * telling the user why we're aborting.
> + */
> +
> +void abort_suspend(const char *fmt, ...)
> +{
> + va_list args;
> + int printed_len = 0;
>
> And your own printk... sweeet.
>
>
> + if (!test_result_state(SUSPEND_ABORTED)) {
> + if (!test_result_state(SUSPEND_ABORT_REQUESTED)) {
> + va_start(args, fmt);
> + printed_len = vsnprintf(local_printf_buf,
> + sizeof(local_printf_buf), fmt, args);
> + va_end(args);
> + if (ui_helper_data.pid != -1)
> + printed_len = sprintf(local_printf_buf + printed_len,
> + " (Press SPACE to continue)");
> + suspend2_prepare_status(CLEAR_BAR, local_printf_buf);
>
> Even if you call userland for actuall printk(), this is still user
> interface.
>
> +#if defined(CONFIG_VT) || defined(CONFIG_SERIAL_CONSOLE)
> + console_loglevel = 7;
> +
> + say("=== Suspend2 ===\n\n");
> + if (warning_reason) {
> + say("BIG FAT WARNING!! %s\n\n", local_printf_buf);
> + switch (message_detail) {
> + case 0:
> + say("If you continue booting, note that any image WILL NOT BE
> REMOVED.\n"); + say("Suspend is unable to do so because the appropriate
> modules aren't\n"); + say("loaded. You should manually remove the image
> to avoid any\n"); + say("possibility of corrupting your filesystem(s)
> later.\n");
> + break;
> + case 1:
> + say("If you want to use the current suspend image, reboot and try\n");
> + say("again with the same kernel that you suspended from. If you
> want\n"); + say("to forget that image, continue and the image will be
> erased.\n"); + break;
> + }
> + say("Press SPACE to reboot or C to continue booting with this
> kernel\n\n"); + say("Default action if you don't select one in %d seconds
> is: %s.\n", + message_timeout,
> + default_answer == SUSPEND_CONTINUE_REQ ?
> + "continue booting" : "reboot");
> + } else {
> + say("BIG FAT WARNING!!\n\n");
> + say("You have tried to resume from this image before.\n");
> + say("If it failed once, it may well fail again.\n");
> + say("Would you like to remove the image and boot normally?\n");
> + say("This will be equivalent to entering noresume2 on the\n");
> + say("kernel command line.\n\n");
> + say("Press SPACE to remove the image or C to continue resuming.\n\n");
> + say("Default action if you don't select one in %d seconds is: %s.\n",
> + message_timeout,
> + !!default_answer ?
> + "continue resuming" : "remove the image");
> + }
>
> Wonderful. Did not we agree that this has no place in kernel?
No, we didn't agree. You said it, and I rejected your assertion. I believe I'm
allowed to listen and disagree.
> + { .filename = "userui_progress_granularity",
> + .permissions = PROC_RW,
> + .type = SUSPEND_PROC_DATA_INTEGER,
> + .data = {
> + .integer = {
> + .variable = &progress_granularity,
> + .minimum = 1,
> + .maximum = 2048,
> + }
> + }
> + },
>
> So even progress granularity is configurable?
Yes. FBsplash can be pretty painful on slow cpus (I think there's some
inefficiency in there that could be addressed, but haven't bothered to do so
myself). Letting users control the progress bar lets them have a nice looking
display without making the process take 10x longer.
> diff -ruN linux-2.6.15-1/kernel/power/ui.h build-2.6.15.1/kernel/power/ui.h
> diff -ruN linux-2.6.15-1/kernel/power/version.h
> build-2.6.15.1/kernel/power/version.h diff -ruN
> linux-2.6.15-1/kernel/sched.c build-2.6.15.1/kernel/sched.c diff -ruN
> linux-2.6.15-1/kernel/signal.c build-2.6.15.1/kernel/signal.c diff -ruN
> linux-2.6.15-1/kernel/softirq.c build-2.6.15.1/kernel/softirq.c diff -ruN
> linux-2.6.15-1/kernel/sys.c build-2.6.15.1/kernel/sys.c
> --- linux-2.6.15-1/kernel/sys.c 2006-01-03 15:08:48.000000000 +1000
> +++ build-2.6.15.1/kernel/sys.c 2006-01-23 21:38:28.000000000 +1000
> @@ -173,15 +173,18 @@
> {
> int ret=NOTIFY_DONE;
> struct notifier_block *nb = *n;
> + struct notifier_block *next;
>
> while(nb)
> {
> - ret=nb->notifier_call(nb,val,v);
> + /* Determining next here allows the notifier to unregister itself */
> + next = nb->next;
> + ret = nb->notifier_call(nb,val,v);
> if(ret&NOTIFY_STOP_MASK)
> {
> return ret;
> }
> - nb=nb->next;
> + nb = next;
> }
> return ret;
> }
>
> What is this?
Christoph's patch, as I said above, no longer in 2.2.0.1.
> diff -ruN linux-2.6.15-1/kernel/workqueue.c
> build-2.6.15.1/kernel/workqueue.c diff -ruN
> linux-2.6.15-1/lib/dyn_pageflags.c build-2.6.15.1/lib/dyn_pageflags.c diff
> -ruN linux-2.6.15-1/lib/Kconfig build-2.6.15.1/lib/Kconfig
> diff -ruN linux-2.6.15-1/lib/Makefile build-2.6.15.1/lib/Makefile
> diff -ruN linux-2.6.15-1/lib/vsprintf.c build-2.6.15.1/lib/vsprintf.c
> diff -ruN linux-2.6.15-1/mm/bootmem.c build-2.6.15.1/mm/bootmem.c
> diff -ruN linux-2.6.15-1/mm/memory.c build-2.6.15.1/mm/memory.c
> --- linux-2.6.15-1/mm/memory.c 2006-01-03 15:08:49.000000000 +1000
> +++ build-2.6.15.1/mm/memory.c 2006-01-23 21:38:28.000000000 +1000
> @@ -950,6 +950,15 @@
> return page;
> }
>
> +/*
> + * We want the address of the page for Suspend2 to mark as being in
> pageset1. + */
> +
> +struct page *suspend2_follow_page(struct mm_struct *mm, unsigned long
> address) +{
> + return follow_page(mm->mmap, address, 0);
> +}
> +
> int get_user_pages(struct task_struct *tsk, struct mm_struct *mm,
> unsigned long start, int len, int write, int force,
> struct page **pages, struct vm_area_struct **vmas)
>
>
> In mm/memory.c? It has a comment, unfortunately it does not say
> anything.
Remember that we save the image in two parts - LRU and rest. Your userspace
program's pages are going to be in the LRU, so to let it run during suspend,
we need to make them part of the atomic copy instead. This lets us find and
mark those pages as not being saved with the rest of the LRU, but instead as
part of the atomic copy.
> diff -ruN linux-2.6.15-1/mm/page_alloc.c build-2.6.15.1/mm/page_alloc.c
> --- linux-2.6.15-1/mm/page_alloc.c 2006-01-03 15:08:49.000000000 +1000
> +++ build-2.6.15.1/mm/page_alloc.c 2006-01-23 21:38:28.000000000 +1000
> @@ -920,8 +921,8 @@
>
> /* This allocation should allow future memory freeing. */
>
> - if (((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE)))
> - && !in_interrupt()) {
> + if ((((p->flags & PF_MEMALLOC) || unlikely(test_thread_flag(TIF_MEMDIE)))
> && + !in_interrupt()) || (test_freezer_state(FREEZER_ON))) {
> if (!(gfp_mask & __GFP_NOMEMALLOC)) {
> nofail_alloc:
> /* go through the zonelist yet again, ignoring mins */
>
> You have just made memory allocation slower. Oops.
Iff the freezer is on (we're suspending) and we actually manage to reach this
far down in the code. (In this case, we're already on the slow path).
> diff -ruN linux-2.6.15-1/mm/pdflush.c build-2.6.15.1/mm/pdflush.c
> diff -ruN linux-2.6.15-1/mm/swapfile.c build-2.6.15.1/mm/swapfile.c
> diff -ruN linux-2.6.15-1/mm/vmscan.c build-2.6.15.1/mm/vmscan.c
> diff -ruN linux-2.6.15-1/net/rxrpc/krxiod.c
> build-2.6.15.1/net/rxrpc/krxiod.c diff -ruN
> linux-2.6.15-1/net/rxrpc/krxsecd.c build-2.6.15.1/net/rxrpc/krxsecd.c diff
> -ruN linux-2.6.15-1/net/rxrpc/krxtimod.c
> build-2.6.15.1/net/rxrpc/krxtimod.c diff -ruN
> linux-2.6.15-1/net/sunrpc/sched.c build-2.6.15.1/net/sunrpc/sched.c diff
> -ruN linux-2.6.15-1/net/sunrpc/svcsock.c
> build-2.6.15.1/net/sunrpc/svcsock.c
>
> So... I'm spreading FUD and suspend2 is not intrusive? I'd not say so.
Look at the diffstat for 2.2.0.1 and re-evaluate this assertion. Look again in
the next release (when I've applied more cleanups).
> And you claimed that uswsusp can not solve anything? With above
> analysis, at least 8040 lines can be moved into userspace. That's more
> than half of your patch...
Remember though that you're making this assertion without actually having done
any of that work. You don't know how much you'll have to add to userspace or
kernel space to make this work. When you've actually done it, and we can
compare apples with apples, then I'll listen to comparisons of lines added
and removed.
> Do we do anything really fundamental in userspace? No. Do you do
> anything fundamental in those 8040 lines? No. => userspace, please.
Writing the image isn't fundamental?
> Now, suspend2 is quite a lot of old code, that does not properly use
> existing kernel infrastructure. Rather than trying to prove suspend2
> is not intrusive (*)... can you just start using Rafael's existing
> code, and put that code into userspace?
I'm not going to waste my time. I have a working implementation today, and if
I were to waste my time porting it to userspace, you'd reject it anyway. If
and when you decide that you want to work on a userspace port, feel free.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Monday 20 February 2006 10:53, Pavel Machek wrote:
> Hi!
>
> > > > It is a lot slower because it does all it's I/O synchronously,
> > > > doesn't compress the image and throws away memory until at least half
> > > > is free.
> > >
> > > uswsusp does compress image (20% speedup, in recent CVS) and do
> > > asynchronous I/O.
> >
> > Only 20? You must be doing something horribly wrong. Asynchronous
>
> 20% is speedup for compression alone, over whole suspend
> process. Device suspend/resume takes lot of time in recent kernels.
Ok. I'm not counting device suspend/resume time, but if you do, the percentage
will vary according to the image size (since the device suspend/resume time
should be independant of image size).
> > > > > > The only con I see is the complexity of the code, but then again,
> > > > > > Nigel
> > > > >
> > > > > ..but thats a big con.
> > > >
> > > > It's fud. Hopefully as I post more suspend2 patches to LKML, people
> > > > will see that Suspend2 is simpler than what you are planning.
> > >
> > > For what I'm planning, all the neccessary patches are already in -mm
> > > tree. And they are *really* simple. If you can get suspend2 to 1000
> > > lines of code (like Rafael did with uswsusp), we can have something to
> > > talk about.
> >
> > Turn it round the right way. If you can get the functionality of Suspend2
> > using userspace only, then we have something to talk about.
>
> Only feature I can't do is "save whole pagecache"... and 14000 lines
> of code for _that_ is a bit too much. I could probably patch my kernel
> to dump pagecache to userspace, but I do not think it is worth the
> effort.
Yes, 14,000 lines for that alone would be a bit too much :)
> > > > Let's be clear. uswsusp is not really moving suspend-to-disk to
> > > > userspace. What it is doing is leaving everything but some code for
> > > > writing the image in kernel space, and implementing ioctls to give a
> > > > userspace program the ability to request that other processes be
> > > > frozen, the snapshot prepared and so on. Pages in the snapshot are
> > > > copied to userspace, possibly compressed or encrypted there in
> > > > future, then fed back to kernel space so it can use the swap routines
> > > > to do the writing. Very little of substance is being done in
> > > > userspace. In short, all it's doing is adding the complexity of
> > >
> > > Maybe very little of substance is being done in userspace, but all the
> > > uglyness can stay there. I no longer need LZF in kernel, special
> > > netlink API for progress bar (progress bar naturally lives in
> > > userland), no plugin infrastructure needed, etc.
> >
> > And you do need?...
>
> I do not need anything more than what is already in -mm tree.
You misunderstand me. Let me reprhase. What additional dependencies do you
have in userspace to support this? libabc, v >= x.y.z etc.
> > > If you can do suspend2 without putting stuff listed above into kernel,
> > > and in acceptable ammount of code... we can see. But you should really
> > > put suspend2 code into userspace, and be done with that. Feel free to
> > > spam l-k a bit more, but using existing infrastructure in -mm is right
> > > way to go, and it is easier, too.
> >
> > It is only easier because you're not comparing apples with apples. I have
> > no desire to spam LKML with this pointless discussion, so I'm just going
> > to get on with submitting patches for review.
>
> So please take my comments from "suspend2 review" mail into account.
Am going, as I do with all responses. Please just remember that taking them
into account doesn't equate to slavishly doing everything suggested.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Friday 17 February 2006 07:53, Pavel Machek wrote:
> > First we had swsusp... For many people it did not work, so
>
> ...no; for many people it was too slow and not nice enough...
>
> > Suspend2 was developed, but was not merged mainly because it
> > had too many UI components in-kernel.
>
> ...and because Nigel did not care about mainline for a *long* time.
Actually, it was more that I didn't want to try to merge something that was
still very much work in progress. You didn't seem to be doing any development
on what was merged, so I didn't foresee any problems with just replacing it
once suspend(1|2|2.1|2.2) became mature. Patrick changed that, and then you
did too. And I learnt about the "merge early, merge often" mantra late in the
game. If I knew then what I know now... but I didn't.
Regards,
Nigel
Hi.
On Sat, Feb 18, 2006 at 03:26:11PM +0100, Pavel Machek wrote:
> Thanks for a fresh air in this flamewar...
Well, I would more like a technical based discussion instead of
flamming. As I said previously, why not have both swsusp and suspend 2
in mainline, as they can coexists without any problem.
> > I have to completly agree with Sebastian here. 16 months ago I was
> > in the need to have a suspend mode running on my new notebook. Back
> > then Suspend 2 was the only choice, and while it had still problems
> > it was surprisingly well behaving (in contrast to S3 mode and the
> > mainline swsusp). The support of the community was, as said above,
> > very good, and most issues very fixed fast.
>
> Can you test recent swsusp?
Maybe I will, but my current setup does not allow this. When Fedora Core
5 comes out in some weeks I will give it a try. But as said, what I want
is a stable and reliable suspend, not something that works in "most of
the cases". Suspend 2 has proved to me and others that is stable.
(BTW: in the last 200 cycles I did with various Suspend 2 versions I had
exactly 1 (_one_) "failure" (Xorg crashed on resume and I had to restart
my windowmanager). That "failure" was not even Suspend 2 related, but a
small bug in Xorg which got already fixed in the meantime.
> > Since it worked good for me, I started to contribute by supplying
> > Fedora patched kernels, helper packages and some documentation.
> > Today on Fedora, it is as easy as installing 4 RPM-packages and
> > adding the "resume2=" parameter to the kernel commandline, and I
> > know that it works this well on several other distributions too.
>
> ...well, thanks for your good work.
You are welcome.
> > Some more numbers: judging from my access logs and the feedback I
> > get, I suspect at least 2000 Fedora users using Suspend 2 on a
> > regular basis with success. Listening to the IRC channel and reading
> > the forums and wikis, I see a huge bunch of people using Suspend 2
> > on nearly every distribution. The problems are incredible low,
> > mostly minor things that get fixed nearly instantly.
>
> Well, at least Fedora and SuSE ship swsusp by default. So it is
> getting huge ammount of testing, too.
No, I do not think so. I do not know about SuSE (although I think you
are right there), but Fedora does _not_ ship swsusp. It was rejected for
a long time because it was considered too dangerous. Recent rawhide as
enabled it, but I doubt there are as many testers for it as there are
for Suspend 2 (on Fedora). That might change with Core 5 (which is
scheduled to be released in March), but I think we have to wait for
that.
> > Some pros of Suspend 2 from my view:
> > - it is reliable and stable (really!)
> > - it is fast (10-30 seconds on my notebook with 1280 MB ram, depending
> > on how much caches are saved)
> > - it can save all buffers and caches and the system is instantly
> > responsible after resume (even Windows cannot do this and is very slow
> > the first minute after resume)
> > - it works on all major platforms (x86, SMP, x86_64, there were success
> > reports for PPC, and I believe even ARM works)
> > - and the most important thing, as already said, it is available _today_
>
> swsusp is also available today, and works better than you think.
OK, I will give it a try in some weeks.
> It is slightly slower,
Sorry, but that is just unacceptable.
> > The only con I see is the complexity of the code, but then again,
> > Nigel
>
> ..but thats a big con.
So why is that? From what I see, most of the code is completly independ
of the rest of the kernel, and just does not affect if it is disabled.
It won't do any harm to the kernel, and again, Nigel is constantly
improving that situation, so for sure, that is no _big_ con.
> > Again, you said the code is complex, it might be, but still most
> > part of the code is completly seperate from the rest of the kernel,
> > and only touches minor things (and Nigel is still working on that).
> > I believe it would not hurt.
>
> It would hurt at least me, Andrew and Linus... It would make lot of
> suspend2 users very happy...
Why would it hurt? See above, I cannot see how Suspend 2 would affect
the rest of the kernel and hurt people who are just not using it.
> > From a user, and contributor, point of view, I really do not
> > understand why not even trying to push a working implementation into
> > mainline (I know that you cannot just apply the Suspend 2 patches
> > and shipping it,
>
> It is less work to port suspend2's features into userspace than to
> make suspend2 acceptable to mainline. Both will mean big changes, and
> may cause some short-term problems, but it will be less pain than
> maintaining suspend2 forever. Please help with the former...
These "big changes" is something I have a problem with, since it means
to delay a working suspend/resume in Linux for another "short-term" (so
what does it mean: 1 month? six? twelve?). It is painful to get these
things to work reliable, I have followed this for nearly 1.5 years. And
again: today there is a working implementation, so why not merge it and
have something today, and then start working on the other things.
I would think that this would help both sides, as it would give us a
working implementation now, and in some time (I would like to believe
you, but sill think that it will take at least one year, maybe two,
until you have uswsusp work stable) the new implementation (and then we
can look which one works better, and maybe deprecate the other).
Regards,
Matthias
Hi.
On Sun, Feb 19, 2006 at 10:29:52PM +0100, Pavel Machek wrote:
> Maybe very little of substance is being done in userspace, but all the
> uglyness can stay there. I no longer need LZF in kernel, special
> netlink API for progress bar (progress bar naturally lives in
> userland), no plugin infrastructure needed, etc.
Linux has a whole crypto API in the kernel, so why is it a problem to
have LZF there too?
About the progress bar: this is already implemented in userspace, the
kernel just forwards the progress via netlink to it. Not necessarily
ugly I think.
Regards,
Matthias
Hi.
On Mon, Feb 20, 2006 at 01:53:33AM +0100, Pavel Machek wrote:
> Only feature I can't do is "save whole pagecache"... and 14000 lines
> of code for _that_ is a bit too much. I could probably patch my kernel
> to dump pagecache to userspace, but I do not think it is worth the
> effort.
I do not think that Suspend 2 needs 14000 lines for that, the core is
much smaller. But besides, _not_ saving the pagecache is a really _bad_
idea. I expect to have my system back after resume, in the same state I
had left it prior to suspend. I really do not like it how it is done by
Windows, it is just ugly to have a slowly responding system after
resume, because all caches and buffers are gone.
I can only speak for myself, but I want to work with my system from the
moment my desktop is back.
Regards,
Matthias
On Mon, 2006-02-20 at 10:39 +0100, Matthias Hensler wrote:
> > It is slightly slower,
>
> Sorry, but that is just unacceptable.
Um... suspend2 puts extra tests into really hot paths like fork(), which
is equally unacceptable to many people.
Why can't people understand that arguing "it works" without any
consideration of possible performance tradeoffs is not a good enough
argument for merging?
Lee
On Monday 20 February 2006 10:39, Matthias Hensler wrote:
> > > The only con I see is the complexity of the code, but then again,
> > > Nigel
> >
> > ..but thats a big con.
>
> So why is that? From what I see, most of the code is completly independ
> of the rest of the kernel, and just does not affect if it is disabled.
>
> It won't do any harm to the kernel, and again, Nigel is constantly
> improving that situation, so for sure, that is no _big_ con.
I might add that you'd drag a devoted developer into the kernel team more
closely, which probably makes up for the 'added complexity' anyway.
The gain in working *together* on suspend2 is worth much more than the 'added
complexity' Pavel complains about. Nigel has stated more than once that he'd
be happy to maintain suspend2, and he's done so for quite some time already,
which proves his point. Nigel is paid to work on suspend2, so it's not likely
to go away once he has a new hobby (and again, he's been doing great work for
some time already).
So what about working on merging suspend2 finally? Having a proven, stable and
feature-rich implemenation available quickly, *and* someone who maintains
*and* support it actively does not sound like a bad deal to me.
One should not underestimate the gains that a suspend2 merge has on the
development merely by stating 'added complexity', that pays off _any_day_.
By the way, does 'working on uswsusp' mean that Pavel and will put less work
in maintaining swsusp? That does not sound too promising to my sore ears.
Personally, to work with, I'd prefer a developer who's responsibly dealing
with users' questions and problems any day to one who rejects 99% of emails
that don't contain a patch and 95% of those that contain one, stating 'WTF, I
don't like that'.
Bottom line: Judging developer resources only by lines of code added does not
make too much sense.
--
sebas
http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Accident, n.: A condition in which presence of mind is good, but absence of
body is better. - Foolish Dictionary
On Mon, 2006-02-20 at 10:39 +0100, Matthias Hensler wrote:
> These "big changes" is something I have a problem with, since it means
> to delay a working suspend/resume in Linux for another
> "short-term" (so
> what does it mean: 1 month? six? twelve?). It is painful to get these
> things to work reliable, I have followed this for nearly 1.5 years.
> And
> again: today there is a working implementation, so why not merge it
> and
> have something today, and then start working on the other things.
It never works that way in practice - if you let broken/suboptimal code
into the kernel then it's a LOT less likely to get fixed later than if
you make fixing it a condition of inclusion because once it's in there's
much less motivation to fix it.
Lee
Hi.
On Mon, Feb 20, 2006 at 05:02:38AM -0500, Lee Revell wrote:
> On Mon, 2006-02-20 at 10:39 +0100, Matthias Hensler wrote:
> > > It is slightly slower,
> >
> > Sorry, but that is just unacceptable.
>
> Um... suspend2 puts extra tests into really hot paths like fork(),
> which is equally unacceptable to many people.
OK, point taken.
> Why can't people understand that arguing "it works" without any
> consideration of possible performance tradeoffs is not a good enough
> argument for merging?
It sure isn't the argument, you are right. My main concern here is to
throw away a working implementation and starting over from the scratch,
instead of solving these problems.
Regards,
Matthias
On Mon, 2006-02-20 at 10:39 +0100, Matthias Hensler wrote:
> > It is less work to port suspend2's features into userspace than to
> > make suspend2 acceptable to mainline. Both will mean big changes,
> and
> > may cause some short-term problems, but it will be less pain than
> > maintaining suspend2 forever. Please help with the former...
>
> These "big changes" is something I have a problem with, since it means
> to delay a working suspend/resume in Linux for another
> "short-term" (so
> what does it mean: 1 month? six? twelve?).
If you have a big problem with this then ask the developer why he didn't
submit it 1 or 6 or 12 months sooner, don't complain to the kernel
developers.
Lee
Hi.
On Mon, Feb 20, 2006 at 05:06:42AM -0500, Lee Revell wrote:
> On Mon, 2006-02-20 at 10:39 +0100, Matthias Hensler wrote:
> > These "big changes" is something I have a problem with, since it
> > means to delay a working suspend/resume in Linux for another
> > "short-term" (so what does it mean: 1 month? six? twelve?). It is
> > painful to get these things to work reliable, I have followed this
> > for nearly 1.5 years. And again: today there is a working
> > implementation, so why not merge it and have something today, and
> > then start working on the other things.
>
> It never works that way in practice - if you let broken/suboptimal
> code into the kernel then it's a LOT less likely to get fixed later
> than if you make fixing it a condition of inclusion because once it's
> in there's much less motivation to fix it.
Isn't this what happend with swusp? I tried it of a period of time when
it was included in mainline, it was just buggy and nothing much
improved.
I totally agree with you that nothing broken should be get into
mainline, but I think that Suspend 2 has be proven to be stable, and it
is worth to put work on it and to fix the remaining issues instead of
just starting from the scratch.
Regards,
Matthias
On Mon, 2006-02-20 at 11:10 +0100, Matthias Hensler wrote:
> > Why can't people understand that arguing "it works" without any
> > consideration of possible performance tradeoffs is not a good enough
> > argument for merging?
>
> It sure isn't the argument, you are right. My main concern here is to
> throw away a working implementation and starting over from the scratch,
> instead of solving these problems.
Take it up with the author for not working more closely with the kernel
developers while Suspend2 was being developed, AFAICT a LOT of this
could have been avoided with better communication.
Lee
Hi.
On Mon, Feb 20, 2006 at 05:11:09AM -0500, Lee Revell wrote:
> On Mon, 2006-02-20 at 10:39 +0100, Matthias Hensler wrote:
> > These "big changes" is something I have a problem with, since it
> > means to delay a working suspend/resume in Linux for another
> > "short-term" (so what does it mean: 1 month? six? twelve?).
>
> If you have a big problem with this then ask the developer why he
> didn't submit it 1 or 6 or 12 months sooner, don't complain to the
> kernel developers.
Well, that is up to Nigel, but he did spend a lot of time to make
Suspend 2 clean and acceptable for the mainline first.
I do not complain that the patch is not inserted as it is. I too see
the problems and open issues. But that is nothing that cannot be solved.
What I complain is to start from the scratch with something which is not
necessarily better and takes a lot of time. I think uswsusp in the
current form just has too many drawbacks.
Regards,
Matthias
On Mon, 2006-02-20 at 11:15 +0100, Matthias Hensler wrote:
> Isn't this what happend with swusp? I tried it of a period of time
> when it was included in mainline, it was just buggy and nothing much
> improved.
And you never explained why you can't try a recent version...
Lee
Hi.
On Mon, Feb 20, 2006 at 05:15:28AM -0500, Lee Revell wrote:
> On Mon, 2006-02-20 at 11:10 +0100, Matthias Hensler wrote:
> > It sure isn't the argument, you are right. My main concern here is
> > to throw away a working implementation and starting over from the
> > scratch, instead of solving these problems.
>
> Take it up with the author for not working more closely with the
> kernel developers while Suspend2 was being developed, AFAICT a LOT of
> this could have been avoided with better communication.
I think Nigel already said that this went wrong, agreed. However, I
remember that this was discussed a lot earlier and Suspend 2 was just
not acceptable for the mainline, so work was done to get it acceptable.
But however, that is really not the point. I would like to go on and
solve the issues with the current problems, and not to start from the
beginning just because of mistakes that were made in the past.
Regards,
Matthias
Hi.
On Mon, Feb 20, 2006 at 05:24:18AM -0500, Lee Revell wrote:
> On Mon, 2006-02-20 at 11:15 +0100, Matthias Hensler wrote:
> > Isn't this what happend with swusp? I tried it of a period of time
> > when it was included in mainline, it was just buggy and nothing much
> > improved.
>
> And you never explained why you can't try a recent version...
I said I surely will :-)
However, there wasn't a recent version until a short time before. I just
did what you do in situations where you need a working solution: you
stick to the most promising thing. While swsusp looked abandoned there
was a huge work going on with Suspend 2.
As work started again on swsusp recently I will try that, but from what
I have read so far it looks like swsusp is scheduled to become
deprecated anyway and work will be put into uswsusp. That is all I
complain about, it means throwing away everything that is working, or
easy to get it working, and delaying working hibernate support for
another time.
Regards,
Matthias
On Po 20-02-06 10:43:00, Matthias Hensler wrote:
> Hi.
>
> On Sun, Feb 19, 2006 at 10:29:52PM +0100, Pavel Machek wrote:
> > Maybe very little of substance is being done in userspace, but all the
> > uglyness can stay there. I no longer need LZF in kernel, special
> > netlink API for progress bar (progress bar naturally lives in
> > userland), no plugin infrastructure needed, etc.
>
> Linux has a whole crypto API in the kernel, so why is it a problem to
> have LZF there too?
Because it is not needed there?
> About the progress bar: this is already implemented in userspace, the
> kernel just forwards the progress via netlink to it. Not necessarily
> ugly I think.
Look at the code.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi.
On Mon, Feb 20, 2006 at 11:36:16AM +0100, Pavel Machek wrote:
> On Po 20-02-06 10:43:00, Matthias Hensler wrote:
> > Linux has a whole crypto API in the kernel, so why is it a problem
> > to have LZF there too?
>
> Because it is not needed there?
Hmmm, I think it makes totally sense there. While it is useful in the
suspend case, it would also be useful to the current implementation that
use the crypto API. Think about creating a compressed volume with
cryptoloop of dm-crypt.
> > About the progress bar: this is already implemented in userspace,
> > the kernel just forwards the progress via netlink to it. Not
> > necessarily ugly I think.
>
> Look at the code.
OK, could you point me to the ugly thinks. I see message passing between
the userspace application and the kernel, for which I think that netlink
is a good choice.
What has to be done to make the code not ugly? Is there a way to fix it
to become acceptable?
Regards,
Matthias
On Po 20-02-06 11:50:16, Matthias Hensler wrote:
> On Mon, Feb 20, 2006 at 11:36:16AM +0100, Pavel Machek wrote:
> > On Po 20-02-06 10:43:00, Matthias Hensler wrote:
> > > About the progress bar: this is already implemented in userspace,
> > > the kernel just forwards the progress via netlink to it. Not
> > > necessarily ugly I think.
> >
> > Look at the code.
>
> OK, could you point me to the ugly thinks. I see message passing between
> the userspace application and the kernel, for which I think that netlink
> is a good choice.
See my comments in "suspend2 review" thread.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Po 20-02-06 10:47:28, Matthias Hensler wrote:
> On Mon, Feb 20, 2006 at 01:53:33AM +0100, Pavel Machek wrote:
> > Only feature I can't do is "save whole pagecache"... and 14000 lines
> > of code for _that_ is a bit too much. I could probably patch my kernel
> > to dump pagecache to userspace, but I do not think it is worth the
> > effort.
>
> I do not think that Suspend 2 needs 14000 lines for that, the core is
> much smaller. But besides, _not_ saving the pagecache is a really _bad_
> idea. I expect to have my system back after resume, in the same state I
> had left it prior to suspend. I really do not like it how it is done by
> Windows, it is just ugly to have a slowly responding system after
> resume, because all caches and buffers are gone.
That's okay, swsusp already saves configurable ammount of pagecache.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Mon, 2006-02-20 at 11:33 +0100, Matthias Hensler wrote:
> That is all I
> complain about, it means throwing away everything that is working, or
> easy to get it working, and delaying working hibernate support for
> another time.
But we have not established that the current implementation does not
work! That's a pretty strong assertion to make with zero evidence.
Lee
Hi.
On Mon, Feb 20, 2006 at 11:54:06AM +0100, Pavel Machek wrote:
> On Po 20-02-06 11:50:16, Matthias Hensler wrote:
> > OK, could you point me to the ugly thinks. I see message passing
> > between the userspace application and the kernel, for which I think
> > that netlink is a good choice.
>
> See my comments in "suspend2 review" thread.
Yes, I read it. Nigel already replied and pointed out that a lot of
things were already fixed and will now be. So the effort to make the
patch acceptable is there.
However, about the User-UI stuff and some things that are implemented in
the kernel, I have to disagree with you. Suspend 2 happily works without
having the userspace UI, which is a good thing as it allows a minimal
setup and a small initrd.
But besides the progress bar I think that some parts have to be in the
kernel, such as the warnings and keyevents to abort the progress. If,
for whatever reason, something goes wrong, you should be able to stop
and abort before doing any damage. If all these things are implemented
in userspace, you need to have a binary in your initrd on the right
place, where is should work without that.
Regards,
Matthias
Hi.
On Mon, Feb 20, 2006 at 11:56:17AM +0100, Pavel Machek wrote:
> On Po 20-02-06 10:47:28, Matthias Hensler wrote:
> > I do not think that Suspend 2 needs 14000 lines for that, the core
> > is much smaller. But besides, _not_ saving the pagecache is a really
> > _bad_ idea. I expect to have my system back after resume, in the
> > same state I had left it prior to suspend. I really do not like it
> > how it is done by Windows, it is just ugly to have a slowly
> > responding system after resume, because all caches and buffers are
> > gone.
>
> That's okay, swsusp already saves configurable ammount of pagecache.
What about uswsusp?
Regards,
Matthias
On Po 20-02-06 12:17:56, Matthias Hensler wrote:
> Hi.
>
> On Mon, Feb 20, 2006 at 11:56:17AM +0100, Pavel Machek wrote:
> > On Po 20-02-06 10:47:28, Matthias Hensler wrote:
> > > I do not think that Suspend 2 needs 14000 lines for that, the core
> > > is much smaller. But besides, _not_ saving the pagecache is a really
> > > _bad_ idea. I expect to have my system back after resume, in the
> > > same state I had left it prior to suspend. I really do not like it
> > > how it is done by Windows, it is just ugly to have a slowly
> > > responding system after resume, because all caches and buffers are
> > > gone.
> >
> > That's okay, swsusp already saves configurable ammount of pagecache.
>
> What about uswsusp?
Same code is used for that.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi.
On Monday 20 February 2006 21:15, Lee Revell wrote:
> On Mon, 2006-02-20 at 11:33 +0100, Matthias Hensler wrote:
> > That is all I
> > complain about, it means throwing away everything that is working, or
> > easy to get it working, and delaying working hibernate support for
> > another time.
>
> But we have not established that the current implementation does not
> work! That's a pretty strong assertion to make with zero evidence.
...and that requires defining 'works'.
If we define it as "writes an image of some part of ram to a swap partition
that can be and does normally get restored on the next boot", then yes, we
have a working version in the existing vanilla kernel. If however you start
talking about multiple swap partitions or swap files or ordinary files, about
reliability or the ability to tune it to fit your system and preferences,
about the responsiveness of the system post resume or the security of the
image (IIRC, encryption support has just been removed from swsusp), about the
ability to get help when you run into trouble or documentation, swsusp
becomes less of a candidate for 'works'.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Monday 20 February 2006 20:56, Pavel Machek wrote:
> On Po 20-02-06 10:47:28, Matthias Hensler wrote:
> > On Mon, Feb 20, 2006 at 01:53:33AM +0100, Pavel Machek wrote:
> > > Only feature I can't do is "save whole pagecache"... and 14000 lines
> > > of code for _that_ is a bit too much. I could probably patch my kernel
> > > to dump pagecache to userspace, but I do not think it is worth the
> > > effort.
> >
> > I do not think that Suspend 2 needs 14000 lines for that, the core is
> > much smaller. But besides, _not_ saving the pagecache is a really _bad_
> > idea. I expect to have my system back after resume, in the same state I
> > had left it prior to suspend. I really do not like it how it is done by
> > Windows, it is just ugly to have a slowly responding system after
> > resume, because all caches and buffers are gone.
>
> That's okay, swsusp already saves configurable ammount of pagecache.
Really? How is it configured?
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Monday 20 February 2006 20:15, Lee Revell wrote:
> On Mon, 2006-02-20 at 11:10 +0100, Matthias Hensler wrote:
> > > Why can't people understand that arguing "it works" without any
> > > consideration of possible performance tradeoffs is not a good enough
> > > argument for merging?
> >
> > It sure isn't the argument, you are right. My main concern here is to
> > throw away a working implementation and starting over from the scratch,
> > instead of solving these problems.
>
> Take it up with the author for not working more closely with the kernel
> developers while Suspend2 was being developed, AFAICT a LOT of this
> could have been avoided with better communication.
Perhaps, but maybe there's more going on here than that.
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Monday 20 February 2006 20:02, Lee Revell wrote:
> On Mon, 2006-02-20 at 10:39 +0100, Matthias Hensler wrote:
> > > It is slightly slower,
> >
> > Sorry, but that is just unacceptable.
>
> Um... suspend2 puts extra tests into really hot paths like fork(), which
> is equally unacceptable to many people.
It doesn't.
Fork is only a 'really hot path' if you have a fork bomb running. The
scheduler is a really hot path (which Suspend2 patches don't touch, by the
way).
The change in the page allocation routine follows a comment saying "This is
the last chance, in general, before the goto nopage." It adds one further
test to the four already done at that point.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Monday 20 February 2006 20:11, Lee Revell wrote:
> On Mon, 2006-02-20 at 10:39 +0100, Matthias Hensler wrote:
> > > It is less work to port suspend2's features into userspace than to
> > > make suspend2 acceptable to mainline. Both will mean big changes,
> >
> > and
> >
> > > may cause some short-term problems, but it will be less pain than
> > > maintaining suspend2 forever. Please help with the former...
> >
> > These "big changes" is something I have a problem with, since it means
> > to delay a working suspend/resume in Linux for another
> > "short-term" (so
> > what does it mean: 1 month? six? twelve?).
>
> If you have a big problem with this then ask the developer why he didn't
> submit it 1 or 6 or 12 months sooner, don't complain to the kernel
> developers.
I submitted it for review 15 months ago. Since then I've been working to apply
the suggestions, clean things up more and finish the last few bits of missing
functionality. Contrary to what Sebas implied earlier, I'm not paid to work
on Suspend2 on a full time basis. I work on it up to 20% of work hours
(thanks, Cyclades), and the remainder of the work is done in my own time.
This often means that things move more slowly than I'd like, but my wife will
happily testify that I still spend too much time on it :)
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Monday 20 February 2006 20:06, Lee Revell wrote:
> On Mon, 2006-02-20 at 10:39 +0100, Matthias Hensler wrote:
> > These "big changes" is something I have a problem with, since it means
> > to delay a working suspend/resume in Linux for another
> > "short-term" (so
> > what does it mean: 1 month? six? twelve?). It is painful to get these
> > things to work reliable, I have followed this for nearly 1.5 years.
> > And
> > again: today there is a working implementation, so why not merge it
> > and
> > have something today, and then start working on the other things.
>
> It never works that way in practice - if you let broken/suboptimal code
> into the kernel then it's a LOT less likely to get fixed later than if
> you make fixing it a condition of inclusion because once it's in there's
> much less motivation to fix it.
I can be an exception, can't I?
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On Mon, 2006-02-20 at 20:40 +1000, Nigel Cunningham wrote:
> I submitted it for review 15 months ago. Since then I've been working
> to apply
> the suggestions, clean things up more and finish the last few bits of
> missing
> functionality. Contrary to what Sebas implied earlier, I'm not paid to
> work
> on Suspend2 on a full time basis. I work on it up to 20% of work
> hours
> (thanks, Cyclades), and the remainder of the work is done in my own
> time.
> This often means that things move more slowly than I'd like, but my
> wife will
> happily testify that I still spend too much time on it :)
My point was simply that "we need this now" is not a good argument for
immediate merging - I was not trying to imply that you aren't working
fast enough ;-)
Lee
On Mon, Feb 20, 2006 at 06:15:46AM -0500, Lee Revell wrote:
> > That is all I complain about, it means throwing away everything that
> > is working, or easy to get it working, and delaying working
> > hibernate support for another time.
>
> But we have not established that the current implementation does not
> work! That's a pretty strong assertion to make with zero evidence.
As I said, it did not work. Efforts to make it work just started
recently, at a time when Suspend 2 already was stable and reliable to
me.
But, ok. Rawhide kernel 2.6.15-1.1955_FC5, which should be pretty close
to what Fedora Core 5 will have (Dave might know this better).
The first try was a desaster, partly my own fault, partly because swsusp
does not allow abortion (remember what I said about having a least some
basic stuff in the kernel). However, I rebooted, fscked, no filesystem
corruption *phew*.
The second try worked, with ugly messages scrolling over the console,
but ok, Suspend 2 already fixes some drivers which has not yet been
merged to mainline. The system resumed, which is fine.
Third try sound was gone. On the fourth try the system hanged after
starting ppracer (to test GLX/DRI on my i855).
This is a much more recent kernel, than the ones I used with Suspend 2
for the last 1.5 problems. Problems discovered have been no issue with
Suspend 2 for at least 7 or 8 months (no single crash or driver
problems). This is mostly a driver issue and undoubtly can be solved,
but I still do not see how this can be done when all efforts are put
into just another suspend implementation (uswsusp).
Ah, and now the part I really like, some hard numbers:
swsusp takes between 26 and 30 seconds to suspend (in my four tries: 26,
30, 28, 26) and between 35 and 45 seconds to resume (35, 45, 39, 37).
Suspend 2 does suspend in around 14-16 seconds, and resume in 18 to 21.
That is factor 2!
Regards,
Matthias
Hi.
On Mon, Feb 20, 2006 at 07:05:52AM -0500, Lee Revell wrote:
> My point was simply that "we need this now" is not a good argument for
> immediate merging
The point "we need this now" is indeed no argument for merging something
which might be broken, but is an argument for working on getting the
most promising solution.
Regards,
Matthias
On Mon, Feb 20, 2006 at 07:05:52AM -0500, Lee Revell wrote:
> My point was simply that "we need this now" is not a good argument for
> immediate merging - I was not trying to imply that you aren't working
> fast enough ;-)
What about "we need this two years ago" ?
I'm having a really hard time convincing myself that Pavel and
friends, while rather good as developpers, haven't succumbed to a bad
case of NIH syndrome. Even with wanting to move as many things to
userspace as possible, merging suspend2 with cleanups if necessary,
_then_ starting from there to move things to userspace seems more
realistic long-term. Right now it really looks like they're only
trying to redo what's already in suspend2, tested and debugged, only
different and new, hence untested and undebugged.
The only thing I've seen that is really against suspend2 is the amount
of code it adds to the kernel. Given that said code is actively
maintained, moving what can be moved to userspace can easily be done
afterwards.
OG.
> Hi.
>
> On Monday 20 February 2006 20:56, Pavel Machek wrote:
> > On Po 20-02-06 10:47:28, Matthias Hensler wrote:
> > > On Mon, Feb 20, 2006 at 01:53:33AM +0100, Pavel Machek wrote:
> > > > Only feature I can't do is "save whole pagecache"... and 14000 lines
> > > > of code for _that_ is a bit too much. I could probably patch my kernel
> > > > to dump pagecache to userspace, but I do not think it is worth the
> > > > effort.
> > >
> > > I do not think that Suspend 2 needs 14000 lines for that, the core is
> > > much smaller. But besides, _not_ saving the pagecache is a really _bad_
> > > idea. I expect to have my system back after resume, in the same state I
> > > had left it prior to suspend. I really do not like it how it is done by
> > > Windows, it is just ugly to have a slowly responding system after
> > > resume, because all caches and buffers are gone.
> >
> > That's okay, swsusp already saves configurable ammount of pagecache.
>
> Really? How is it configured?
If you want to limit the suspend image size to N bytes, do
echo N > /sys/power/image_size
before suspend (it is limited to 500 MB by default).
Pavel
--
Thanks, Sharp!
> Hi.
>
> On Monday 20 February 2006 21:15, Lee Revell wrote:
> > On Mon, 2006-02-20 at 11:33 +0100, Matthias Hensler wrote:
> > > That is all I
> > > complain about, it means throwing away everything that is working, or
> > > easy to get it working, and delaying working hibernate support for
> > > another time.
> >
> > But we have not established that the current implementation does not
> > work! That's a pretty strong assertion to make with zero evidence.
>
> ...and that requires defining 'works'.
>
> If we define it as "writes an image of some part of ram to a swap partition
> that can be and does normally get restored on the next boot", then yes, we
> have a working version in the existing vanilla kernel. If however you start
> talking about multiple swap partitions or swap files or ordinary files, about
> reliability or the ability to tune it to fit your system and preferences,
> about the responsiveness of the system post resume or the security of the
> image (IIRC, encryption support has just been removed from swsusp), about the
> ability to get help when you run into trouble or documentation, swsusp
> becomes less of a candidate for 'works'.
...so yes, it works, and the rest of features can be implemented in
userspace. Feel free to help with documentation or userspace parts.
Pavel
--
Thanks, Sharp!
> On Mon, Feb 20, 2006 at 06:15:46AM -0500, Lee Revell wrote:
> > > That is all I complain about, it means throwing away everything that
> > > is working, or easy to get it working, and delaying working
> > > hibernate support for another time.
> >
> > But we have not established that the current implementation does not
> > work! That's a pretty strong assertion to make with zero evidence.
>
> As I said, it did not work. Efforts to make it work just started
> recently, at a time when Suspend 2 already was stable and reliable to
> me.
That is not true.
> But, ok. Rawhide kernel 2.6.15-1.1955_FC5, which should be pretty close
> to what Fedora Core 5 will have (Dave might know this better).
>
> The first try was a desaster, partly my own fault, partly because swsusp
> does not allow abortion (remember what I said about having a least some
> basic stuff in the kernel). However, I rebooted, fscked, no filesystem
> corruption *phew*.
Abortion can be done in userspace. Perhaps even as easily as ^c during
the suspend script.
> The second try worked, with ugly messages scrolling over the console,
> but ok, Suspend 2 already fixes some drivers which has not yet been
> merged to mainline. The system resumed, which is fine.
Submit driver fixes, then.
> Third try sound was gone. On the fourth try the system hanged after
> starting ppracer (to test GLX/DRI on my i855).
Submit AGP fixes, then.
> This is a much more recent kernel, than the ones I used with Suspend 2
> for the last 1.5 problems. Problems discovered have been no issue with
> Suspend 2 for at least 7 or 8 months (no single crash or driver
> problems). This is mostly a driver issue and undoubtly can be solved,
> but I still do not see how this can be done when all efforts are put
> into just another suspend implementation (uswsusp).
uswsusp & swsusp & suspend2 share underlying drivers. If Nigel has
some fixes he had not propagated upstream... that is not *my* fault.
(Or you can help here, take relevant driver updates from suspend2 and
submit them yourself.)
> Ah, and now the part I really like, some hard numbers:
> swsusp takes between 26 and 30 seconds to suspend (in my four tries: 26,
> 30, 28, 26) and between 35 and 45 seconds to resume (35, 45, 39, 37).
>
> Suspend 2 does suspend in around 14-16 seconds, and resume in 18 to 21.
>
> That is factor 2!
Does that include time to boot resume kernel? It will not be that
dramatic with that time included, and it is only fair to include
it. Anyway uswsusp solves that issue.
Pavel
--
Thanks, Sharp!
> Hi.
>
> On Monday 20 February 2006 20:02, Lee Revell wrote:
> > On Mon, 2006-02-20 at 10:39 +0100, Matthias Hensler wrote:
> > > > It is slightly slower,
> > >
> > > Sorry, but that is just unacceptable.
> >
> > Um... suspend2 puts extra tests into really hot paths like fork(), which
> > is equally unacceptable to many people.
>
> It doesn't.
>
> Fork is only a 'really hot path' if you have a fork bomb running. The
> scheduler is a really hot path (which Suspend2 patches don't touch, by the
> way).
Heh, tell that to Andrew and people running configure scripts. With
attitude like this, do you wonder why you can't get a patch merged?
Pavel
--
Thanks, Sharp!
> Hi.
>
> On Monday 20 February 2006 20:06, Lee Revell wrote:
> > On Mon, 2006-02-20 at 10:39 +0100, Matthias Hensler wrote:
> > > These "big changes" is something I have a problem with, since it means
> > > to delay a working suspend/resume in Linux for another
> > > "short-term" (so
> > > what does it mean: 1 month? six? twelve?). It is painful to get these
> > > things to work reliable, I have followed this for nearly 1.5 years.
> > > And
> > > again: today there is a working implementation, so why not merge it
> > > and
> > > have something today, and then start working on the other things.
> >
> > It never works that way in practice - if you let broken/suboptimal code
> > into the kernel then it's a LOT less likely to get fixed later than if
> > you make fixing it a condition of inclusion because once it's in there's
> > much less motivation to fix it.
>
> I can be an exception, can't I?
I do not trust you to be an exception, sorry. Your behaviour up to now
also suggests you will not be.
Pavel
--
Thanks, Sharp!
Hi.
On Mon, Feb 20, 2006 at 02:28:42PM +0100, Pavel Machek wrote:
> > On Mon, Feb 20, 2006 at 06:15:46AM -0500, Lee Revell wrote:
> > > But we have not established that the current implementation does
> > > not work! That's a pretty strong assertion to make with zero
> > > evidence.
> >
> > As I said, it did not work. Efforts to make it work just started
> > recently, at a time when Suspend 2 already was stable and reliable
> > to me.
>
> That is not true.
What? That Suspend 2 was stable for me that time? Yes, it definitly
was. The same time when swsusp failed dramatically here, if there was
progress I could not see it that time.
> > The first try was a desaster, partly my own fault, partly because
> > swsusp does not allow abortion (remember what I said about having a
> > least some basic stuff in the kernel). However, I rebooted, fscked,
> > no filesystem corruption *phew*.
>
> Abortion can be done in userspace. Perhaps even as easily as ^c during
> the suspend script.
Actually this was on resume, while the kernel was in full control. With
Suspend 2 I could have pressed escape (that is the ugly stuff you
complained about), while I had to fully restart the system with sysrq+b
with swsusp.
> > The second try worked, with ugly messages scrolling over the
> > console, but ok, Suspend 2 already fixes some drivers which has not
> > yet been merged to mainline. The system resumed, which is fine.
>
> Submit driver fixes, then.
Nigel did, that is why the patch is so huge.
> > Third try sound was gone. On the fourth try the system hanged after
> > starting ppracer (to test GLX/DRI on my i855).
>
> Submit AGP fixes, then.
I think no such fixes are in Suspend 2, but still it works there.
> > This is a much more recent kernel, than the ones I used with Suspend
> > 2 for the last 1.5 problems. Problems discovered have been no issue
> > with Suspend 2 for at least 7 or 8 months (no single crash or driver
> > problems). This is mostly a driver issue and undoubtly can be
> > solved, but I still do not see how this can be done when all efforts
> > are put into just another suspend implementation (uswsusp).
>
> uswsusp & swsusp & suspend2 share underlying drivers. If Nigel has
> some fixes he had not propagated upstream... that is not *my* fault.
Read again, I already said that this are some driver problems, and I
think that most of them are already submitted.
But then again, this was about work/not work, and there are still
problems, so there is still efford needed. In this situation it is not
good to just start over, but take the things that are already there and
work with it.
> > Ah, and now the part I really like, some hard numbers: swsusp takes
> > between 26 and 30 seconds to suspend (in my four tries: 26, 30, 28,
> > 26) and between 35 and 45 seconds to resume (35, 45, 39, 37).
> >
> > Suspend 2 does suspend in around 14-16 seconds, and resume in 18 to
> > 21.
> >
> > That is factor 2!
>
> Does that include time to boot resume kernel? It will not be that
> dramatic with that time included, and it is only fair to include it.
Actually it is, yes. This time is dramatic and includes the full time I
see from a user point of view.
Time for suspend was measured from the time I started hibernate (Suspend
2)/echoed disk into /sys/power/state (swsusp) until the moment the
notebook powered down.
Time for resume was measured from the time I pressed enter in grub and
the system was back will full X and drivers and ready to work.
I think this is a fair time comparision, and it is a dramatic factor of
2. (BTW: the time from powering on the notebook until the grub-menu
comes up takes 3 seconds, so feel free to add this. It would not make a
huge difference.)
However, this test was made with very empty caches, I suspect after some
more work when the caches get filled, this will change even more
dramatically, thanks to LZF compression (which might be in uswsusp, but
is not in swsusp).
> Anyway uswsusp solves that issue.
Maybe it will, but when?
I looks like that we are at the same point we started from: swsusp had a
lot of problems in the past and is still not working so great and also
very slow. Suspend 2 has proved to be stable and reliable for nearly a
year. Work on uswsusp has just started and needs a lot of time to become
mature.
And here is my point again: take the easiest way to make hibernation
working fast, and when that is done start to work on any new
implementation.
Regards,
Matthias
On 2/20/06, Lee Revell <[email protected]> wrote:
> On Mon, 2006-02-20 at 10:39 +0100, Matthias Hensler wrote:
> > > It is slightly slower,
> >
> > Sorry, but that is just unacceptable.
>
> Um... suspend2 puts extra tests into really hot paths like fork(), which
> is equally unacceptable to many people.
>
How bad is it really? From what I saw marking that swsuspend2 branch
with "unlikely" should help the hot path.
> Why can't people understand that arguing "it works" without any
> consideration of possible performance tradeoffs is not a good enough
> argument for merging?
Many of Pavel's arguments are not about performance tradeoffs but
about perceived complexity of the code. I think if Nigel could run a
clean up on his implementation and split it into couple of largish
(not for inclusion but for general overview) pieces, like separate
arch support, generally useful bits and the rest it would allow seeing
more clearly how big and invasive swsuspend2 core is.
--
Dmitry
> On Mon, Feb 20, 2006 at 02:28:42PM +0100, Pavel Machek wrote:
> > > On Mon, Feb 20, 2006 at 06:15:46AM -0500, Lee Revell wrote:
> > > As I said, it did not work. Efforts to make it work just started
> > > recently, at a time when Suspend 2 already was stable and reliable
> > > to me.
> >
> > That is not true.
>
> What? That Suspend 2 was stable for me that time? Yes, it definitly
> was. The same time when swsusp failed dramatically here, if there was
> progress I could not see it that time.
"That efforts to fix swsusp only started recently" part is
untrue. Driver work was pretty much done from the time swsusp was
merged, and is ongoing.
> > > The first try was a desaster, partly my own fault, partly because
> > > swsusp does not allow abortion (remember what I said about having a
> > > least some basic stuff in the kernel). However, I rebooted, fscked,
> > > no filesystem corruption *phew*.
> >
> > Abortion can be done in userspace. Perhaps even as easily as ^c during
> > the suspend script.
>
> Actually this was on resume, while the kernel was in full control. With
> Suspend 2 I could have pressed escape (that is the ugly stuff you
> complained about), while I had to fully restart the system with sysrq+b
> with swsusp.
You should be able to ^c resume script, too. (But that's going to
cause problems anyway, no?)
> > > The second try worked, with ugly messages scrolling over the
> > > console, but ok, Suspend 2 already fixes some drivers which has not
> > > yet been merged to mainline. The system resumed, which is fine.
> >
> > Submit driver fixes, then.
>
> Nigel did, that is why the patch is so huge.
No, he did not. Driver fixes should be sent to relevant maintainers,
not as a part of "suspend2 -- merge this"...
> > > This is a much more recent kernel, than the ones I used with Suspend
> > > 2 for the last 1.5 problems. Problems discovered have been no issue
> > > with Suspend 2 for at least 7 or 8 months (no single crash or driver
> > > problems). This is mostly a driver issue and undoubtly can be
> > > solved, but I still do not see how this can be done when all efforts
> > > are put into just another suspend implementation (uswsusp).
> >
> > uswsusp & swsusp & suspend2 share underlying drivers. If Nigel has
> > some fixes he had not propagated upstream... that is not *my* fault.
>
> Read again, I already said that this are some driver problems, and I
> think that most of them are already submitted.
You read again. As drivers are common in swsusp and uswsusp
cases... of course we are working on fixing that.
> But then again, this was about work/not work, and there are still
> problems, so there is still efford needed. In this situation it is not
> good to just start over, but take the things that are already there and
> work with it.
I seen Nigel's recent patch. Yes, it is easier to just start
over. (8000 unneccessary lines... that's 3 times size of swsusp with
uswsusp included!)
> I think this is a fair time comparision, and it is a dramatic factor of
> 2. (BTW: the time from powering on the notebook until the grub-menu
> comes up takes 3 seconds, so feel free to add this. It would not make a
> huge difference.)
>
> However, this test was made with very empty caches, I suspect after some
> more work when the caches get filled, this will change even more
> dramatically, thanks to LZF compression (which might be in uswsusp, but
> is not in swsusp).
>
> > Anyway uswsusp solves that issue.
>
> Maybe it will, but when?
It works today, try it.
> And here is my point again: take the easiest way to make hibernation
> working fast, and when that is done start to work on any new
> implementation.
I'm not interested in "easiest way to fast hibernation". I'm
interested in "right way to fast hibernation".
Pavel
--
Thanks, Sharp!
Pavel Machek <[email protected]> writes:
>> Ah, and now the part I really like, some hard numbers:
>> swsusp takes between 26 and 30 seconds to suspend (in my four tries: 26,
>> 30, 28, 26) and between 35 and 45 seconds to resume (35, 45, 39, 37).
>>
>> Suspend 2 does suspend in around 14-16 seconds, and resume in 18 to 21.
>>
>> That is factor 2!
>
> Does that include time to boot resume kernel? It will not be that
> dramatic with that time included, and it is only fair to include
> it. Anyway uswsusp solves that issue.
On my old ThinkPad, the difference is more like a factor of 3 to 4 -
from the moment I press the power button until X is up and running.
Suspend2 resumes faster than Windows 2000 on this machine.
--
Hilsen Harald.
Hi,
On Monday 20 February 2006 13:31, Olivier Galibert wrote:
> On Mon, Feb 20, 2006 at 07:05:52AM -0500, Lee Revell wrote:
> > My point was simply that "we need this now" is not a good argument for
> > immediate merging - I was not trying to imply that you aren't working
> > fast enough ;-)
>
> What about "we need this two years ago" ?
>
> I'm having a really hard time convincing myself that Pavel and
> friends, while rather good as developpers, haven't succumbed to a bad
> case of NIH syndrome.
Actually "Pavel and frieds" are Pavel and _me_ and _I_ don't like what
you're saying here.
> Even with wanting to move as many things to
> userspace as possible, merging suspend2 with cleanups if necessary,
> _then_ starting from there to move things to userspace seems more
> realistic long-term.
The _only_ thing we moved to the user space was the writing and reading
of the image. [We moved it quite literally, by porting the analogous swsusp
code from the current -mm.]
Currently we are _not_ moving _anything_ to the user space. We're just
_implementing_ some things in the user space, but _not_ from scratch.
> Right now it really looks like they're only
> trying to redo what's already in suspend2, tested and debugged, only
> different and new, hence untested and undebugged.
Actually a lot of the code that we use _has_ _been_ tested and debugged,
because it _is_ used on a daily basis by many people, like eg.:
- MD5 from the coreutils package,
- libLZF (the original one)
(openSSL wil be used soon for the image encryption).
And I'm not trying to redo suspend2 in the user space. Instead I'm trying
to use the code that's _already_ _available_ in the user space to obtain
the functionality that suspend2 implements in the kernel space.
> The only thing I've seen that is really against suspend2 is the amount
> of code it adds to the kernel. Given that said code is actively
> maintained, moving what can be moved to userspace can easily be done
> afterwards.
The problem is to merge suspend2 we'd have to clean it up first and
actually solve some problems that it works around. That, arguably,
would be more work than just implementing some _easy_ stuff
in the user space.
Greetings,
Rafael
> On 2/20/06, Lee Revell <[email protected]> wrote:
> > On Mon, 2006-02-20 at 10:39 +0100, Matthias Hensler wrote:
> > > > It is slightly slower,
> > >
> > > Sorry, but that is just unacceptable.
> >
> > Um... suspend2 puts extra tests into really hot paths like fork(), which
> > is equally unacceptable to many people.
> >
>
> How bad is it really? From what I saw marking that swsuspend2 branch
> with "unlikely" should help the hot path.
Not too bad, really.
> > Why can't people understand that arguing "it works" without any
> > consideration of possible performance tradeoffs is not a good enough
> > argument for merging?
>
> Many of Pavel's arguments are not about performance tradeoffs but
> about perceived complexity of the code. I think if Nigel could run a
> clean up on his implementation and split it into couple of largish
> (not for inclusion but for general overview) pieces, like separate
> arch support, generally useful bits and the rest it would allow seeing
> more clearly how big and invasive swsuspend2 core is.
I have so many complains I do not know what to complain about,
first. My main one is:
"This can be done in userspace" (on recent -mm).
then there are some more, like "this is 14000 lines of code" and "it
touches places it should not really touch" (and maybe "its author does
not understand how linux development works", to some extent).
Pavel
--
Thanks, Sharp!
Pavel Machek wrote:
..
> ...so yes, it works...
About 50% of the time for me. The rest of the time I just
see a complete fresh boot from scratch. What a pain!
-ml
> Pavel Machek wrote:
> ..
> >...so yes, it works...
>
> About 50% of the time for me. The rest of the time I just
> see a complete fresh boot from scratch. What a pain!
Ouch... strange. Does it work reliably from init=/bin/bash boot? Do
you see final steps of writing on the screen? Can you submit it to
bugzilla.kernel.org?
Pavel
--
Thanks, Sharp!
On 2/20/06, Pavel Machek <[email protected]> wrote:
> > Pavel Machek wrote:
> > ..
> > >...so yes, it works...
> >
> > About 50% of the time for me. The rest of the time I just
> > see a complete fresh boot from scratch. What a pain!
>
> Ouch... strange. Does it work reliably from init=/bin/bash boot? Do
> you see final steps of writing on the screen? Can you submit it to
> bugzilla.kernel.org?
>
I know I am bad for not reporting that earlier but swsusp was working
OK for me till about 3 month ago when I started getting "soft lockup
detected on CPU0" with no useable backtrace 3 times out of 4. I
somehow suspect that having automounted nfs helps it to fail
somehow...
For the record - I never tried swsuspend2 as I am tracking the tip of
Linus's tree and prefre to have the tree clean for my work anyway.
--
Dmitry
Hi.
On Mon, Feb 20, 2006 at 03:07:19PM +0100, Pavel Machek wrote:
> > On Mon, Feb 20, 2006 at 02:28:42PM +0100, Pavel Machek wrote:
> > What? That Suspend 2 was stable for me that time? Yes, it definitly
> > was. The same time when swsusp failed dramatically here, if there
> > was progress I could not see it that time.
>
> "That efforts to fix swsusp only started recently" part is untrue.
> Driver work was pretty much done from the time swsusp was merged, and
> is ongoing.
As I did not really follow the ongoing work that time I will believe you
here.
So I am left to my statement that Suspend 2 worked for nearly one year,
where swsusp still has issues.
> You should be able to ^c resume script, too. (But that's going to
> cause problems anyway, no?)
In this case swsusp wanted to restore an already invalid image (had a
reboot with fsck before) which would have resulted in filesystem
corruption. If you are able to stop the resume process with ^C that is
fine, but that needs the "ugly" eventhandler in the kernel (which I
think is not so ugly at all).
As I said, this situation was partly my own fault, and we do not need to
discuss this further. It just reminds me on the bad things that could be
happen.
> > Nigel did, that is why the patch is so huge.
>
> No, he did not. Driver fixes should be sent to relevant maintainers,
> not as a part of "suspend2 -- merge this"...
I think most patches were already submitted upstream. And I think we all
agree that this is the way how it should happen.
So, cleanups are still necessary, and I believe Nigel mentioned that he
is already working on it.
> > But then again, this was about work/not work, and there are still
> > problems, so there is still efford needed. In this situation it is
> > not good to just start over, but take the things that are already
> > there and work with it.
>
> I seen Nigel's recent patch. Yes, it is easier to just start over.
> (8000 unneccessary lines... that's 3 times size of swsusp with uswsusp
> included!)
Correct me if I am wrong, but I see your comments are about Suspend 2.2,
while a lot of this was already be fixed in 2.2.0.1.
And Nigel has taken your points and preparing a new patch. So let see
when it is ready.
> > > Anyway uswsusp solves that issue.
> >
> > Maybe it will, but when?
>
> It works today, try it.
Using -mm is not an issue for me at the moment, so I cannot test it. I
will believe you with that, however I doubt that uswsusp is in any
better state than Suspend 2 when it comes to stability, reliabilty,
documentation and availability of working packages (at least I see no
userbase).
I do not say that uswsusp will not work, or never will, but I say that
it is far from finished, that is why it should be considered to use the
other solution first.
> > And here is my point again: take the easiest way to make hibernation
> > working fast, and when that is done start to work on any new
> > implementation.
>
> I'm not interested in "easiest way to fast hibernation". I'm
> interested in "right way to fast hibernation".
OK, for me the "right way" is to take the working solution and work
around the problems and issues that are left and prevent it from getting
into mainline.
Regards,
Matthias
> Pavel Machek <[email protected]> writes:
>
> >> Ah, and now the part I really like, some hard numbers:
> >> swsusp takes between 26 and 30 seconds to suspend (in my four tries: 26,
> >> 30, 28, 26) and between 35 and 45 seconds to resume (35, 45, 39, 37).
> >>
> >> Suspend 2 does suspend in around 14-16 seconds, and resume in 18 to 21.
> >>
> >> That is factor 2!
> >
> > Does that include time to boot resume kernel? It will not be that
> > dramatic with that time included, and it is only fair to include
> > it. Anyway uswsusp solves that issue.
>
> On my old ThinkPad, the difference is more like a factor of 3 to 4 -
> from the moment I press the power button until X is up and running.
Well, yep, it really depends on CPU/harddisk.
Can you try code from suspend.sf.net? It should be as fast as
suspend2.
Pavel
--
Thanks, Sharp!
Hi.
On Mon, Feb 20, 2006 at 03:42:54PM +0100, Pavel Machek wrote:
> Well, yep, it really depends on CPU/harddisk.
That is why a solution using LZF is needed, so either Suspend 2 or
uswsusp.
> Can you try code from suspend.sf.net? It should be as fast as
> suspend2.
I would like to have a look at it, but http://suspend.sourceforge.net/
gives me an empty directory and http://sourceforge.net/suspend/ a "page
not found".
Regards,
Matthias
> On 2/20/06, Pavel Machek <[email protected]> wrote:
> > > Pavel Machek wrote:
> > > ..
> > > >...so yes, it works...
> > >
> > > About 50% of the time for me. The rest of the time I just
> > > see a complete fresh boot from scratch. What a pain!
> >
> > Ouch... strange. Does it work reliably from init=/bin/bash boot? Do
> > you see final steps of writing on the screen? Can you submit it to
> > bugzilla.kernel.org?
> >
>
> I know I am bad for not reporting that earlier but swsusp was working
> OK for me till about 3 month ago when I started getting "soft lockup
> detected on CPU0" with no useable backtrace 3 times out of 4. I
> somehow suspect that having automounted nfs helps it to fail
> somehow...
Disable soft lockup watchdog :-).
Pavel
--
Thanks, Sharp!
> Hi.
>
> On Mon, Feb 20, 2006 at 03:42:54PM +0100, Pavel Machek wrote:
> > Well, yep, it really depends on CPU/harddisk.
>
> That is why a solution using LZF is needed, so either Suspend 2 or
> uswsusp.
>
> > Can you try code from suspend.sf.net? It should be as fast as
> > suspend2.
>
> I would like to have a look at it, but http://suspend.sourceforge.net/
> gives me an empty directory and http://sourceforge.net/suspend/ a "page
> not found".
Ahha, sorry, go to http://www.sf.net/projects/suspend/ , then check out code
from CVS, there's nice description how to do that there.
Pavel
--
Thanks, Sharp!
Hi!
> > > But then again, this was about work/not work, and there are still
> > > problems, so there is still efford needed. In this situation it is
> > > not good to just start over, but take the things that are already
> > > there and work with it.
> >
> > I seen Nigel's recent patch. Yes, it is easier to just start over.
> > (8000 unneccessary lines... that's 3 times size of swsusp with uswsusp
> > included!)
>
> Correct me if I am wrong, but I see your comments are about Suspend 2.2,
> while a lot of this was already be fixed in 2.2.0.1.
>
> And Nigel has taken your points and preparing a new patch. So let see
> when it is ready.
Well... I trust that all the typos and =0 and // comments are going to
be fixed, but I somehow doubt he'll switch to mainline code and drop
his bitmaps or drop plugin architecture. If 2.2.0.2 is 8000 lines
smaller... I'd be pleasently surprised.
Pavel
--
Thanks, Sharp!
On 2/20/06, Pavel Machek <[email protected]> wrote:
> >
> > I know I am bad for not reporting that earlier but swsusp was working
> > OK for me till about 3 month ago when I started getting "soft lockup
> > detected on CPU0" with no useable backtrace 3 times out of 4. I
> > somehow suspect that having automounted nfs helps it to fail
> > somehow...
>
> Disable soft lockup watchdog :-).
Ok, I will try, but is this the permanent solution you are proposing?
--
Dmitry
On Mon, Feb 20, 2006 at 03:13:23PM +0100, Rafael J. Wysocki wrote:
> Actually "Pavel and frieds" are Pavel and _me_ and _I_ don't like what
> you're saying here.
Sorry about that. Look at the thread though, and the answers to
questions of the "suspend2 as feature <x>" kind. They tend to be
either "you don't need it" or "we need to reimplement it". That looks
like a bad syndrome of NIHing to me and I should know, I catch myself
often enough at it. It's really, really hard to admit that code that
you write yourself, for which you will instinctively know your way
around much better, may not in practice be better long term that what
already exists. Often enough just because what already exists
obviously existed for longer than code you're going to write and as a
result has been way more debugged.
> > Even with wanting to move as many things to
> > userspace as possible, merging suspend2 with cleanups if necessary,
> > _then_ starting from there to move things to userspace seems more
> > realistic long-term.
>
> The _only_ thing we moved to the user space was the writing and reading
> of the image. [We moved it quite literally, by porting the analogous swsusp
> code from the current -mm.]
>
> Currently we are _not_ moving _anything_ to the user space. We're just
> _implementing_ some things in the user space, but _not_ from scratch.
>From what I see of the messages in this thread, at that point you're
just trying to play catchup with suspend2. Don't that feel a little
strange to you? You know you have working GPL code handy, tested with
happy users, with a maintainer who would be happy to have it in the
kernel, and instead of making it better you spend your talents redoing
the same functionality only slightly differently. Why? Just for a
semireligious argument on where the userspace/kernelspace separation
should be in the suspend process?
> > Right now it really looks like they're only
> > trying to redo what's already in suspend2, tested and debugged, only
> > different and new, hence untested and undebugged.
>
> Actually a lot of the code that we use _has_ _been_ tested and debugged,
> because it _is_ used on a daily basis by many people, like eg.:
> - MD5 from the coreutils package,
> - libLZF (the original one)
> (openSSL wil be used soon for the image encryption).
>
> And I'm not trying to redo suspend2 in the user space. Instead I'm trying
> to use the code that's _already_ _available_ in the user space to obtain
> the functionality that suspend2 implements in the kernel space.
"obtaining the functionality that suspend2 implements" means "redoing
suspend2". Don't play on words, please.
md5 is already in the kernel (twice). lzf is already in suspend2 (and
arguably useful for more things than only suspending), so suspend2's
implementation has been tested for use in a suspend context, while
libLZF hasn't. You _will_ have bugs putting things together, that's a
given.
Now explain me why you're tying together code from coreutils and other
sources when you have the same code, only already tested in a suspend
context (memory management, etc), in suspend2. Why, for the image
save, did you port the code from swsusp with for instance its lack of
async i/o, instead of porting the suspend2 code?
> The problem is to merge suspend2 we'd have to clean it up first and
> actually solve some problems that it works around. That, arguably,
> would be more work than just implementing some _easy_ stuff in the
> user space.
Stuff that is _already_ _done_ and working.
Be careful though, you're awfully close to saying that userspace code
is easier because it isn't reviewed[1] while kernel code has higher
standards. I really doubt it from you guys, but it looks like that.
Ask yourself some important questions and see if you like the answers:
1- will uswsusp solve problems suspend2 doesn't? Real, currently
encountered problems, not philosophical problems about
kernel/userspace code positions[2]. In particular, since according
to Pavel 90+% of the problems are driver issues, why aren't you
concentrating on drivers?
2- in the time you're going to need to reimplement all the features of
suspend2 and stabilize the code, wouldn't it be possible to fix the
worked-around problems of suspend2? Will you ever be able to be as
stable as suspend2 given the heads-up that code has?
3- if the main problem is really that some parts of suspend2 should be
in userspace instead of kernelspace, why aren't you working from the
appropriate parts of the suspend2 code to port them to userspace use
instead of going to coreutils/libLZF/etc? The constraints on
userland suspend code are rather close to RT kernel code, so
technically it would be a much better base.
4- why aren't you actively working at pushing the parts of suspend2
that actually are good and potentially useful to uswsusp in the
mainline kernel. Do you really think nothing is worthwhile in there?
Are you really, really sure you're not rejecting suspend2 in bulk
because you didn't write it? Do we need a John W. Linville as suspend
maintainer for things to go better?
Please tell me what is wrong in my perception of what is going on.
OG, not even a suspend2 user.
[1] Look at s2ram.c and puke. I understand it has been clobbed
together for testing and as such does not pretend to be of any
quality, but it's so bad it's painful.
[2] Otherwise you can start net5 in userspace just because it doesn't
absolutely need to be in kernelspace.
On Monday 20 February 2006 16:08, Dmitry Torokhov wrote:
> On 2/20/06, Pavel Machek <[email protected]> wrote:
> > >
> > > I know I am bad for not reporting that earlier but swsusp was working
> > > OK for me till about 3 month ago when I started getting "soft lockup
> > > detected on CPU0" with no useable backtrace 3 times out of 4. I
> > > somehow suspect that having automounted nfs helps it to fail
> > > somehow...
> >
> > Disable soft lockup watchdog :-).
>
> Ok, I will try, but is this the permanent solution you are proposing?
Certainly not.
The problem is the soft lockup watchdog tends to produce false-positives
related to the clock resume vs timer interrupt dependencies that are
hard to trace.
I used to get those on a regular basis until the timer resume on x86-64
got fixed a month ago or so.
Please try the latest -mm and see if it's not fixed there. If not, please
file a bug report with bugzilla (with Cc to me).
Greetings,
Rafael
On 2006-02-20, Olivier Galibert <[email protected]> wrote:
> On Mon, Feb 20, 2006 at 03:13:23PM +0100, Rafael J. Wysocki wrote:
>> Actually a lot of the code that we use _has_ _been_ tested and debugged,
>> because it _is_ used on a daily basis by many people, like eg.:
>> - MD5 from the coreutils package,
>> - libLZF (the original one)
>> (openSSL wil be used soon for the image encryption).
>>
>> And I'm not trying to redo suspend2 in the user space. Instead I'm trying
>> to use the code that's _already_ _available_ in the user space to obtain
>> the functionality that suspend2 implements in the kernel space.
>
> "obtaining the functionality that suspend2 implements" means "redoing
> suspend2". Don't play on words, please.
through using the userspace helper he is able to use existing maintained
libaries, something that isn't possible with kernelspace suspend. This
is real code reduction.
> md5 is already in the kernel (twice). lzf is already in suspend2 (and
> arguably useful for more things than only suspending),
Why (when LZF would be useful for other stuff) nobody proposed inclusion
of it?
>> The problem is to merge suspend2 we'd have to clean it up first and
>> actually solve some problems that it works around. That, arguably,
>> would be more work than just implementing some _easy_ stuff in the
>> user space.
>
> Stuff that is _already_ _done_ and working.
While reading this 'discussion' I get the expression that swsusp isn't
working. But this isn't true: it works for me since I can't remember
when. The only problems were with some modules (ieee1394 had to be
unloaded before suspending) and minor glinches (writing the image
sometimes _very_ slow when suspending from a powersave cpufreq
governor..).
> 1- will uswsusp solve problems suspend2 doesn't? Real, currently
> encountered problems, not philosophical problems about
> kernel/userspace code positions[2].
swsusp works for me (TM), no problems at all, siree
> In particular, since according
> to Pavel 90+% of the problems are driver issues, why aren't you
> concentrating on drivers?
so submit driver specific patches through the driver's maintainer? Where
does Pavel enter the picture?
> 3- if the main problem is really that some parts of suspend2 should be
> in userspace instead of kernelspace, why aren't you working from the
> appropriate parts of the suspend2 code to port them to userspace use
> instead of going to coreutils/libLZF/etc?
code dupplication?
> 4- why aren't you actively working at pushing the parts of suspend2
> that actually are good and potentially useful to uswsusp in the
> mainline kernel. Do you really think nothing is worthwhile in there?
Maybe the mentioned problems with bitmaps and the module infrastructure
could explain that. Even Nigel said that the problem with evolutionary
patches is that suspend2 changes some fundamentals.
> Are you really, really sure you're not rejecting suspend2 in bulk
> because you didn't write it? Do we need a John W. Linville as suspend
> maintainer for things to go better?
Are you really threatening Pavel's position as maintainer? how subtle.
> Please tell me what is wrong in my perception of what is going on.
>
> OG, not even a suspend2 user.
andy, a long time swsusp user.
> [2] Otherwise you can start net5 in userspace just because it doesn't
> absolutely need to be in kernelspace.
it seems like "Van Jacobson's network channels" [0] would move some
stuff to userspace. Are you volunteering? (dislaimer: I have just
glimpsed at the article).
[0] http://lwn.net/Articles/169961/
On 2/20/06, Rafael J. Wysocki <[email protected]> wrote:
> On Monday 20 February 2006 16:08, Dmitry Torokhov wrote:
> > On 2/20/06, Pavel Machek <[email protected]> wrote:
> > > >
> > > > I know I am bad for not reporting that earlier but swsusp was working
> > > > OK for me till about 3 month ago when I started getting "soft lockup
> > > > detected on CPU0" with no useable backtrace 3 times out of 4. I
> > > > somehow suspect that having automounted nfs helps it to fail
> > > > somehow...
> > >
> > > Disable soft lockup watchdog :-).
> >
> > Ok, I will try, but is this the permanent solution you are proposing?
>
> Certainly not.
>
> The problem is the soft lockup watchdog tends to produce false-positives
> related to the clock resume vs timer interrupt dependencies that are
> hard to trace.
>
> I used to get those on a regular basis until the timer resume on x86-64
> got fixed a month ago or so.
>
> Please try the latest -mm and see if it's not fixed there. If not, please
> file a bug report with bugzilla (with Cc to me).
>
Latest -mm is way too big a target. Do you have a specific patches in
mind? Again my working kernel is based off tip of Linus's tree plus my
patches, not -mm.
--
Dmitry
Hi!
> > It is slightly slower,
>
> Sorry, but that is just unacceptable.
Eh? Slower suspend is not acceptable while slowing runtime system is
acceptable?
> > > The only con I see is the complexity of the code, but then again,
> > > Nigel
> >
> > ..but thats a big con.
>
> So why is that? From what I see, most of the code is completly independ
> of the rest of the kernel, and just does not affect if it is disabled.
>
> It won't do any harm to the kernel, and again, Nigel is constantly
> improving that situation, so for sure, that is no _big_ con.
14000 lines is a lot of code to maintain.
> > > From a user, and contributor, point of view, I really do not
> > > understand why not even trying to push a working implementation into
> > > mainline (I know that you cannot just apply the Suspend 2 patches
> > > and shipping it,
> >
> > It is less work to port suspend2's features into userspace than to
> > make suspend2 acceptable to mainline. Both will mean big changes, and
> > may cause some short-term problems, but it will be less pain than
> > maintaining suspend2 forever. Please help with the former...
>
> These "big changes" is something I have a problem with, since it means
> to delay a working suspend/resume in Linux for another "short-term" (so
> what does it mean: 1 month? six? twelve?). It is painful to get these
> things to work reliable, I have followed this for nearly 1.5 years. And
> again: today there is a working implementation, so why not merge it and
> have something today, and then start working on the other things.
swsusp is reliable; suspend2 is faster... If you can't wait six months
for uswsusp (which is as fast, today)... help me with uswsusp.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi!
> > > > > > > The only con I see is the complexity of the code, but then again,
> > > > > > > Nigel
> > > > > >
> > > > > > ..but thats a big con.
> > > > >
> > > > > It's fud. Hopefully as I post more suspend2 patches to LKML, people
> > > > > will see that Suspend2 is simpler than what you are planning.
> > > >
> > > > For what I'm planning, all the neccessary patches are already in -mm
> > > > tree. And they are *really* simple. If you can get suspend2 to 1000
> > > > lines of code (like Rafael did with uswsusp), we can have something to
> > > > talk about.
> > >
> > > Turn it round the right way. If you can get the functionality of Suspend2
> > > using userspace only, then we have something to talk about.
> >
> > Only feature I can't do is "save whole pagecache"... and 14000 lines
> > of code for _that_ is a bit too much. I could probably patch my kernel
> > to dump pagecache to userspace, but I do not think it is worth the
> > effort.
>
> Yes, 14,000 lines for that alone would be a bit too much :)
Great we agree on that... because "save whole pagecache" is the only
feature that is not possible with current uswsusp code.
> > > And you do need?...
> >
> > I do not need anything more than what is already in -mm tree.
>
> You misunderstand me. Let me reprhase. What additional dependencies do you
> have in userspace to support this? libabc, v >= x.y.z etc.
Currently it depends on libc, and optionaly at liblzf. We'll probably
add libssl dependency later.
BUT NONE OF THIS MATTERS. suspend.sf.net is only one implementation,
you are welcome to do different one. If we cared about userland
dependencies, we could simply include all the libraries into
suspend.sf.net's CVS.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi!
[Most fundamental stuff is at the end].
> > > > > The only con I see is the complexity of the code, but then again,
> > > > > Nigel
> > > >
> > > > ..but thats a big con.
> > >
> > > It's fud. Hopefully as I post more suspend2 patches to LKML, people will
> > > see that Suspend2 is simpler than what you are planning.
> >
> > Well, good luck with that. But since you claimed I'm spreading FUD, I
> > think I'll have to go through your patch.
> >
> > Ouch, it is 500KB, 19K lines. How can you claim it is not complex?!
>
> Size != complexity. Not necessarily.
Well, it is complex in this particular case.
> > Unrelated to suspend2; either push it or drop it. [There are more such
> > changes, even for architectures you do not support suspend on... or do
> > you support suspend on h8300?]
>
> This is because you got 2.2 instead of the latest-devel patch. It (and some
> changes mentioned below) are got now (2.2.0.1).
I could not see 2.2.0.1 on the web page...
> > diff -ruN linux-2.6.15-1/arch/x86_64/kernel/e820.c
> > build-2.6.15.1/arch/x86_64/kernel/e820.c diff -ruN
> > linux-2.6.15-1/arch/x86_64/kernel/signal.c
> > build-2.6.15.1/arch/x86_64/kernel/signal.c
> >
> > diff -ruN linux-2.6.15-1/arch/x86_64/kernel/suspend.c
> > build-2.6.15.1/arch/x86_64/kernel/suspend.c
> >
> > With uswsusp, you are using existing code...
>
> If I could use your existing code, I would. Unfortunately I'm using a more
> compact method of storing the data (bitmaps), and I reckon I have zero chance
> of getting you to switch.
And what chance do I have in getting _you_ to switch? Mainline code
was fixed _long_ ago not to need higher order allocations, and rafael
made it pretty compact lately, IIRC.
Please either switch to kernel code, or explain me that bitmaps have
serious-enough advantage that I want to switch.
> > diff -ruN linux-2.6.15-1/Documentation/kernel-parameters.txt
> > build-2.6.15.1/Documentation/kernel-parameters.txt ---
> > linux-2.6.15-1/Documentation/kernel-parameters.txt 2006-01-03
> > 15:08:24.000000000 +1000 +++
> > build-2.6.15.1/Documentation/kernel-parameters.txt 2006-01-23
> > 21:38:28.000000000 +1000 @@ -71,6 +71,7 @@
> > SERIAL Serial support is enabled.
> > SMP The kernel is an SMP kernel.
> > SPARC Sparc architecture is enabled.
> > + SUSPEND2 Suspend2 is enabled.
> > SWSUSP Software suspend is enabled.
> > TS Appropriate touchscreen support is enabled.
> > USB USB support is enabled.
> > @@ -966,6 +967,8 @@
> > noresume [SWSUSP] Disables resume and restores original swap
> > space.
> >
> > + noresume2 [SUSPEND2] Disables resuming and restores original swap
> > signature. +
> > no-scroll [VGA] Disables scrollback.
> > This is required for the Braillex ib80-piezo Braille
> > reader made by F.H. Papenmeier (Germany).
> >
> > ...and kernel parameters do not need to change...
>
> This is only because I'm deliberately not stomping on your code at the moment.
I would actually like you to stomp on my code. Anything else can't
lead to swsusp->suspend2 evolution...
> > -91,7 +91,7 @@
> > "Access to PCI configuration space unavailable\n");
> > return AE_NULL_ENTRY;
> > }
> > - kacpid_wq = create_singlethread_workqueue("kacpid");
> > + kacpid_wq = create_nofreeze_singlethread_workqueue("kacpid");
> > BUG_ON(!kacpid_wq);
> >
> > return AE_OK;
> >
> > Big search and replace all over the tree. Changes the default to
> > unsafe one. Do you ever listen to comments?
>
> "Changes the default to unsafe one"? It makes the default to be freezing
> kernel threads, which should be safer since they then won't unexpectedly do
> (random action).
Well, you have just declared kacpid "NOFREEZE" here. I think Rafael
explained to you why these are bad idea. If not, convince me they are
good idea, but search&replace all over the tree is bad idea. (And
current patches seem to work just fine).
> > Same here. You should be able to use mainline's snapshot
> > functionality. That's common piece between swsusp and suspend2, and
> > having your own copy helps noone.
>
> As mentioned above, I use a different method of storing the meta data
> (bitmaps). It's more space efficient, but I expect you won't want it because
> it will make your asm longer.
Metadata are very small part of data being saved. How much space does
it save in kernel image? It adds quite a lot of complexity....
> > Why do you need to modify printf-like functions?!
>
> It's not modified, but a new one. IIRC, the closest one to what I was after
> didn't return the info I needed.
Can you modify the caller? Noone else in kernel needs this printf-like
variant, you should probably modify your code not to need it, too.
> > Why can't you just use existing code for atomic copy?
> >
> > (~400 lines of duplicated code skipped)
>
> As mentioned above, different data structures; the code isn't duplicated.
Switch to in-kernel data structures, then...
> > So you have your own disk operations... Nothing like that is needed
> > with uswsusp.
>
> They're just the routines shared by the writers (which shoudl really be called
> something different now that I've moved all the real work to this file :>). I
> think I could further clean this up, removing the header specific routines.
> And the point to it all is doing the async I/O and readahead, given just
> lists of blocks on devices and (via these routines) the pages to write. If
> uswsusp supported swapfiles and ordinary files, it would have something like
> this.
Maybe it would have something like this *in userspace*. Certainly not
in kernel.
> > Snipped 600 lines of code that can happily live in userspace.
>
> You can use cryptoapi from userspace?
No, but I can link to liblzf/libssl just fine. And I think it is even
possible to ask kernel to do crypto for you, not sure.
> > +/*
> > + * kernel/power/suspend2_core/encryption.c
> > + *
> > + * Copyright (C) 2003-2005 Nigel Cunningham <[email protected]>
> > + *
> > + * This file is released under the GPLv2.
> > + *
> > + * This file contains data encryption routines for suspend,
> > + * using cryptoapi transforms.
> > + *
> > + * ToDo:
> > + * - Apply min/max_keysize the cipher changes.
> > + * - Test.
> > + */
> >
> > Snipped 550 lines of code that can happily live in userspace.
>
> (if cryptoapi can be used from there).
You don't need to use cryptoapi. Take a look at ssh, does it use
cryptoapi? No. Is it broken? No.
> > diff -ruN linux-2.6.15-1/kernel/power/extent.c
> > build-2.6.15.1/kernel/power/extent.c ---
> > linux-2.6.15-1/kernel/power/extent.c 1970-01-01 10:00:00.000000000 +1000
> > +++ build-2.6.15.1/kernel/power/extent.c 2006-01-23 21:38:28.000000000
> > +1000 @@ -0,0 +1,247 @@
> > +/* kernel/power/suspend2_core/extent.c
> > + *
> > + * (C) 2003-2005 Nigel Cunningham <[email protected]>
> > + *
> > + * Distributed under GPLv2.
> > + *
> > + * These functions encapsulate the manipulation of storage metadata. For
> > + * pageflags, we use dynamically allocated bitmaps.
> > + */
> > +
> >
> > I do not know why you want to use extents; existing code seems to work
> > well enough. Do you get .01% speedup or what?
>
> They're used for storing the lists of blocks on each dev in which we store the
> image. It has nothing to do with a speedup, but rather efficient storage of
> the metadata.
So... this is some code that is needed for swapfiles/normal files but
not for swap partitions?
> > +static int suspend2_nl_gen_rcv_msg(struct user_helper_data *uhd,
> > + struct sk_buff *skb, struct nlmsghdr *nlh)
> > +{
> > + int type;
> > + int *data;
> > + int err;
> > +
> > + /* Let the more specific handler go first. It returns
> > + * 1 for valid messages that it doesn't know. */
> > + if ((err = uhd->rcv_msg(skb, nlh)) != 1)
> > + return err;
> >
> >
> > ...some of them pretty cryptic.
>
> True. Will add to to do list :)
No need to clean it up, just switch to Rafael's solution ;-).
> > +static int launch_userpace_program(struct user_helper_da
> > + sprintf(channel, "-c%d", uhd->netlink_id);
> > + argv[arg] = channel;
> > +
> > + retval = call_usermodehelper(argv[0], argv, envp, 0);
> >
> > It is really better if userspace calls you...
>
> Well, this way, we don't care if userspace doesn't come to the party. We can
> still suspend and resume without it.
Well, that should not be a big problem. We can get distros to ship
swsusp, and they use initrd-s, anyway.
> > +void suspend_power_down(void)
> > +{
> > + if (test_action_state(SUSPEND_REBOOT)) {
> > + suspend2_prepare_status(DONT_CLEAR_BAR, "Ready to reboot.");
> > + kernel_restart(NULL);
> > + }
> >
> > And we do not want UI code in kernel.
>
> This is telling the UI what to do (as opposed to userspace telling the kernel
> what to do ;-)).
Yes, and it is why userspace telling kernel what to do is
superior. You'd need to internationalize this etc.
> > +1000 +++ build-2.6.15.1/kernel/power/prepare_image.c 2006-01-23
> > 21:38:28.000000000 +1000 @@ -0,0 +1,753 @@
> > +/*
> > + * kernel/power/prepare_image.c
> > + *
> > + * Copyright (C) 2003-2005 Nigel Cunningham <[email protected]>
> > + *
> > + * This file is released under the GPLv2.
> > + *
> > + * We need to eat memory until we can:
> > + * 1. Perform the save without changing anything (RAM_NEEDED < max_pfn)
> > + * 2. Fit it all in available space (active_writer->available_space() >=
> > + * storage_needed())
> > + * 3. Reload the pagedir and pageset1 to places that don't collide with
> > their + * final destinations, not knowing to what extent the resumed
> > kernel will + * overlap with the one loaded at boot time. I think the
> > resumed kernel + * should overlap completely, but I don't want to rely
> > on this as it is + * an unproven assumption. We therefore assume there
> > will be no overlap at + * all (worse case).
> > + * 4. Meet the user's requested limit (if any) on the size of the image.
> > + * The limit is in MB, so pages/256 (assuming 4K pages).
> > + *
> > + */
> >
> > There's existing code in kernel to do this, no?
>
> No. It doesn't support letting the user configure the limit they want (without
> requiring a recompile) and it doesn't support storing a full image of memory.
> It is cleaner and simpler, but I'm not sure it would work as reliably under
> stress. I know I have cleanups to do here. There are surely still leftovers
> from when we used that memory pool and I know I currently have a bug to chase
> down.
Can you start the other way? Try kernel method, and if you can break
it, fix it; rather than replacing it with completely new code?
> > Well, we probably do not want more junk in /proc. And this would not
> > be neccessary if (surprise) userspace controlled suspend. 300 lines
> > unneeeded, and 70 lines in header.
>
> :) But you would need more ioctls.
:-).
> > --- linux-2.6.15-1/kernel/power/storage.c 1970-01-01 10:00:00.000000000
> > +1000 +++ build-2.6.15.1/kernel/power/storage.c 2006-01-23
> > 21:38:28.000000000 +1000 @@ -0,0 +1,323 @@
> > +/*
> > + * kernel/power/storage.c
> > + *
> > + * Copyright (C) 2005 Nigel Cunningham <[email protected]>
> > + *
> > + * This file is released under the GPLv2.
> > + *
> > + * Routines for talking to a userspace program that manages storage.
> > + *
> > + * The kernel side:
> > + * - starts the userspace program;
> > + * - sends messages telling it when to open and close the connection;
> > + * - tells it when to quit;
> > + *
> > + * The user space side:
> > + * - passes messages regarding status;
> >
> > Yep, if you do it all in userspace, this vanishes. 340 lines down.
>
> And you gain? Let's try not to be too biased :).
I gain 340 less lines to review. For me to review, for akpm to review,
and for Linus to review. That's important.
> > + * Copyright 2004-2005 Nigel Cunningham <[email protected]>
> > + *
> > + * Distributed under GPLv2.
> > + *
> > + * This file contains block io functions for suspend2. These are
> > + * used by the swapwriter and it is planned that they will also
> > + * be used by the NFSwriter.
> > + *
> > + */
> >
> > 1080 lines that are not neccessary in uswsusp case, because we can
> > simply use existing read/write routines.
>
> But only if you stick to only supporting writing to a single swap parttiion.
I don't see this, why?
userland parts of swsusp code still have access to normal read/write
syscalls. I can write to normal (not swap) partition very easily, and
in fact first version of uswsusp done that.
> > Can happily live in userspace (using bmap), 1070 lines down.
>
> How would you do the I/O once you'd bmapped? I thought you rejected bios.
Plain read/write syscalls on partition are safe.
> > +char suspend_wait_for_keypress(int timeout)
> > +{
> > + int fd;
> > + char key = '\0';
> > + struct termios t, t_backup;
> > +
> > + if (ui_helper_data.pid != -1) {
> > + wait_for_key_via_userui();
> > + key = ' ';
> > + goto out;
> > + }
> > +
> > + /* We should be guaranteed /dev/console exists after populate_rootfs() in
> > + * init/main.c
> > + */
> > + if ((fd = sys_open("/dev/console", O_RDONLY, 0)) < 0) {
> > + printk("Couldn't open /dev/console.\n");
> > + goto out;
> > + }
> >
> > ...and you still do user interface in kernel, despite having userland
> > helper.
>
> printks, yes. You don't do any printks?
I don't need to open files in kernel, that's quite a big "no-no".
> > + say("BIG FAT WARNING!!\n\n");
> > + say("You have tried to resume from this image before.\n");
> > + say("If it failed once, it may well fail again.\n");
> > + say("Would you like to remove the image and boot normally?\n");
> > + say("This will be equivalent to entering noresume2 on the\n");
> > + say("kernel command line.\n\n");
> > + say("Press SPACE to remove the image or C to continue resuming.\n\n");
> > + say("Default action if you don't select one in %d seconds is: %s.\n",
> > + message_timeout,
> > + !!default_answer ?
> > + "continue resuming" : "remove the image");
> > + }
> >
> > Wonderful. Did not we agree that this has no place in kernel?
>
> No, we didn't agree. You said it, and I rejected your assertion. I believe I'm
> allowed to listen and disagree.
And I'm allowed to NAK your patches, if you want to take it to this
level. Piece above is enough to NAK whole series. How do you
internationalize it, for example?
> > So... I'm spreading FUD and suspend2 is not intrusive? I'd not say so.
>
> Look at the diffstat for 2.2.0.1 and re-evaluate this assertion. Look again in
> the next release (when I've applied more cleanups).
You can clean it up any way you want to, but half of your code should
not be in kernel in the first place.
> > And you claimed that uswsusp can not solve anything? With above
> > analysis, at least 8040 lines can be moved into userspace. That's more
> > than half of your patch...
>
> Remember though that you're making this assertion without actually having done
> any of that work. You don't know how much you'll have to add to userspace or
> kernel space to make this work. When you've actually done it, and we can
> compare apples with apples, then I'll listen to comparisons of lines added
> and removed.
I'm pretty sure I don't have anything in kernel to add...
> > Do we do anything really fundamental in userspace? No. Do you do
> > anything fundamental in those 8040 lines? No. => userspace, please.
>
> Writing the image isn't fundamental?
Actually, no, writing the image isn't fundamental. You can send it
over network, or do something like that...
> > Now, suspend2 is quite a lot of old code, that does not properly use
> > existing kernel infrastructure. Rather than trying to prove suspend2
> > is not intrusive (*)... can you just start using Rafael's existing
> > code, and put that code into userspace?
>
> I'm not going to waste my time. I have a working implementation today, and if
> I were to waste my time porting it to userspace, you'd reject it anyway. If
> and when you decide that you want to work on a userspace port, feel free.
You are missing few things:
*) you are wasting your time, anyway, by cleaning code that does not
belong into kernel in the first place.
*) I'd probably not reject your patches to userspace parts. My biggest
complain about your code is that it lives in kernel space while it
should live in userland.
*) I can't really reject userspace patches. I'm not distribution
maintainer, and only a distribution can do that.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Po 20-02-06 12:17:24, Matthias Hensler wrote:
> Hi.
>
> On Mon, Feb 20, 2006 at 11:54:06AM +0100, Pavel Machek wrote:
> > On Po 20-02-06 11:50:16, Matthias Hensler wrote:
> > > OK, could you point me to the ugly thinks. I see message passing
> > > between the userspace application and the kernel, for which I think
> > > that netlink is a good choice.
> >
> > See my comments in "suspend2 review" thread.
>
> Yes, I read it. Nigel already replied and pointed out that a lot of
> things were already fixed and will now be. So the effort to make the
> patch acceptable is there.
Yep, Nigel fixes typo every time I show him one. That only shows how
old his code is, and how little review it got.
That's not making patch acceptable. His patch still duplicates lots of
kernel code, and puts code into kernelspace that can be done userspace
as well.
If you want to merge some code in kernelspace, you should do it in
small pieces, and should understand what existing code does. Nigel
does not care what existing code does. If swsusp contained problem 2
years ago, but mainline fixed it, Nigel still includes his
workarounds. (See his bitmap stuff). That's not the way to go.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Po 20-02-06 20:44:48, Nigel Cunningham wrote:
> Hi.
>
> On Monday 20 February 2006 20:15, Lee Revell wrote:
> > On Mon, 2006-02-20 at 11:10 +0100, Matthias Hensler wrote:
> > > > Why can't people understand that arguing "it works" without any
> > > > consideration of possible performance tradeoffs is not a good enough
> > > > argument for merging?
> > >
> > > It sure isn't the argument, you are right. My main concern here is to
> > > throw away a working implementation and starting over from the scratch,
> > > instead of solving these problems.
> >
> > Take it up with the author for not working more closely with the kernel
> > developers while Suspend2 was being developed, AFAICT a LOT of this
> > could have been avoided with better communication.
>
> Perhaps, but maybe there's more going on here than that.
Yes, there is:
1) you don't really watch mainline development.
2) you are not trying to improve mainline suspend, all you want is to
merge suspend2.
3) you ask me to trust you to clean it up after merge.
4) you still have code that was declared unacceptable 12 months
ago. ("press C to continue..." from kernel!)
5) you refuse to use existing mainline features, even through bugs
that forced you to reimplement them were fixed _long_ time ago.
6) you spread FUD about swsusp. (I.e. latest attempt to redefine
"working").
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Po 20-02-06 11:20:52, Matthias Hensler wrote:
> Hi.
>
> On Mon, Feb 20, 2006 at 05:11:09AM -0500, Lee Revell wrote:
> > On Mon, 2006-02-20 at 10:39 +0100, Matthias Hensler wrote:
> > > These "big changes" is something I have a problem with, since it
> > > means to delay a working suspend/resume in Linux for another
> > > "short-term" (so what does it mean: 1 month? six? twelve?).
> >
> > If you have a big problem with this then ask the developer why he
> > didn't submit it 1 or 6 or 12 months sooner, don't complain to the
> > kernel developers.
>
> Well, that is up to Nigel, but he did spend a lot of time to make
> Suspend 2 clean and acceptable for the mainline first.
As I said.. Nigel is fixing small problems but not the big ones.
> I do not complain that the patch is not inserted as it is. I too see
> the problems and open issues. But that is nothing that cannot be solved.
Nigel is unviling to solve that. I pointed out 8000 lines of code
(>50% of his patch) that can better be done in userspace. I do not
think he's willing to address that.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Po 20-02-06 11:05:34, Sebastian K?gler wrote:
> On Monday 20 February 2006 10:39, Matthias Hensler wrote:
> > > > The only con I see is the complexity of the code, but then again,
> > > > Nigel
> > >
> > > ..but thats a big con.
> >
> > So why is that? From what I see, most of the code is completly independ
> > of the rest of the kernel, and just does not affect if it is disabled.
> >
> > It won't do any harm to the kernel, and again, Nigel is constantly
> > improving that situation, so for sure, that is no _big_ con.
>
> I might add that you'd drag a devoted developer into the kernel team more
> closely, which probably makes up for the 'added complexity' anyway.
I'd love to have Nigel helping me and kernel, but he's not
interested. He wants suspend2 merged, he does not want better suspend
in kernel.
> The gain in working *together* on suspend2 is worth much more than the 'added
> complexity' Pavel complains about. Nigel has stated more than once that he'd
> be happy to maintain suspend2, and he's done so for quite some time already,
> which proves his point. Nigel is paid to work on suspend2, so it's not likely
> to go away once he has a new hobby (and again, he's been doing great work for
> some time already).
I do not think he's paid for suspend2 any more.
> So what about working on merging suspend2 finally? Having a proven, stable and
> feature-rich implemenation available quickly, *and* someone who maintains
> *and* support it actively does not sound like a bad deal to me.
Nigel is not really maintaining it. He's willing to solve small
problems, but not the big ones.
> One should not underestimate the gains that a suspend2 merge has on the
> development merely by stating 'added complexity', that pays off _any_day_.
>
> By the way, does 'working on uswsusp' mean that Pavel and will put less work
> in maintaining swsusp? That does not sound too promising to my sore ears.
uswsusp and swsusp share most of the important code (go take a
look). No, in-kernel swap writing is not going to be improved too
much, just the bugs fixed. That means very stable swsusp in kernel...
> Personally, to work with, I'd prefer a developer who's responsibly dealing
> with users' questions and problems any day to one who rejects 99% of emails
> that don't contain a patch and 95% of those that contain one, stating 'WTF, I
> don't like that'.
Fine, feel free to help with answering users mails.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi!
> > > Even with wanting to move as many things to
> > > userspace as possible, merging suspend2 with cleanups if necessary,
> > > _then_ starting from there to move things to userspace seems more
> > > realistic long-term.
> >
> > The _only_ thing we moved to the user space was the writing and reading
> > of the image. [We moved it quite literally, by porting the analogous swsusp
> > code from the current -mm.]
> >
> > Currently we are _not_ moving _anything_ to the user space. We're just
> > _implementing_ some things in the user space, but _not_ from scratch.
>
> >From what I see of the messages in this thread, at that point you're
> just trying to play catchup with suspend2. Don't that feel a little
> strange to you? You know you have working GPL code handy, tested with
> happy users, with a maintainer who would be happy to have it in the
> kernel, and instead of making it better you spend your talents redoing
> the same functionality only slightly differently. Why? Just for a
> semireligious argument on where the userspace/kernelspace separation
> should be in the suspend process?
There is 14000 lines of code that is very far away from being
mergeable into kernel. It is less work to reimplement it in userspace
than clean it up for kernel inclusion.
And no, Nigel is *not* willing to help. He's willing to fix small
problems, but not big ones.
> > The problem is to merge suspend2 we'd have to clean it up first and
> > actually solve some problems that it works around. That, arguably,
> > would be more work than just implementing some _easy_ stuff in the
> > user space.
>
> Stuff that is _already_ _done_ and working.
It is not done. It is too ugly, and it is not done in a way that could
be merged into kernel.
> Are you really, really sure you're not rejecting suspend2 in bulk
> because you didn't write it? Do we need a John W. Linville as suspend
> maintainer for things to go better?
>
> Please tell me what is wrong in my perception of what is going on.
>
> OG, not even a suspend2 user.
...and probably never seen suspend2 patch.
If you see suspend2 patch, and still feel some parts of it are good
and could be reused in userspace, feel free to help.
> [1] Look at s2ram.c and puke. I understand it has been clobbed
> together for testing and as such does not pretend to be of any
> quality, but it's so bad it's painful.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On 2/20/06, Pavel Machek <[email protected]> wrote:
> I'd love to have Nigel helping me and kernel, but he's not
> interested. He wants suspend2 merged, he does not want better suspend
> in kernel.
You are waaaay out of line!!!!
We _ALL_ want a better suspend in kernel!
You are the one who reject all other ideas and offerings.
I think that almost every one who follow/read the thread understand
that... Maybe except of you...
> Nigel is not really maintaining it. He's willing to solve small
> problems, but not the big ones.
What?
It is a pleasure to work with Nigel!!! Unlike some other people here.
Just read the suspend2 mailing lists and understand... Or maybe you
are too blind to understand how to approach people.
When was the last time _YOU_ offered a new feature that helps the end-user?
In fact swsusp is the one that is not maintained... It is just a toy
for some programmers to say: "Hay I know to do that differently!"
> uswsusp and swsusp share most of the important code (go take a
> look). No, in-kernel swap writing is not going to be improved too
> much, just the bugs fixed. That means very stable swsusp in kernel...
But both will not be able to write image to a file, right?
Both will not be able to write the image to the network, right?
And what about the administrative interface (/proc), this is also not provided.
So swsusp and uswsusp will never reach the level of suspend2... Some
of us understand that... But of course you reject the need... And
going your way.... Although you know that providing the same level of
features will require more in-kernel modifications.
Pavel, people are trying to help you!
It is one thing to reject their help.
But why to insult them?
Alon Bar-Lev.
On Mon, Feb 20, 2006 at 01:49:37PM +0100, Pavel Machek wrote:
> > > Yep, if you do it all in userspace, this vanishes. 340 lines down.
> >
> > And you gain? Let's try not to be too biased :).
>
> I gain 340 less lines to review. For me to review, for akpm to review,
> and for Linus to review. That's important.
Pavel, if you mean that the userspace code will not be reviewed to
standards the kernel code is, kill uswsusp _NOW_ before it does too
much damage. Unreliable suspend eats filesystems for breakfast. The
other userspace components of the kernels services are either optional
(udev) or not that important (alsa).
OG.
On Po 20-02-06 18:05:37, Olivier Galibert wrote:
> On Mon, Feb 20, 2006 at 01:49:37PM +0100, Pavel Machek wrote:
> > > > Yep, if you do it all in userspace, this vanishes. 340 lines down.
> > >
> > > And you gain? Let's try not to be too biased :).
> >
> > I gain 340 less lines to review. For me to review, for akpm to review,
> > and for Linus to review. That's important.
>
> Pavel, if you mean that the userspace code will not be reviewed to
> standards the kernel code is, kill uswsusp _NOW_ before it does too
> much damage. Unreliable suspend eats filesystems for breakfast. The
> other userspace components of the kernels services are either optional
> (udev) or not that important (alsa).
At least it will be only me reviewing it, and not akpm and Linus.
suspend2 received no such review, and still people claim it is
reliable. "I wish they'd kill suspend2 project, it already did enough
damage." (Half joking here, but suspend2 split user/development
community, and that's not good).
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Mon, Feb 20, 2006 at 02:01:25PM +0100, Pavel Machek wrote:
> I'd love to have Nigel helping me and kernel, but he's not
> interested. He wants suspend2 merged, he does not want better suspend
> in kernel.
If you made comments like that about me on a public mailing list I
would feel it would be very difficult trying to cooperate with you.
Please reconsider your public replies regarding this already delicate
issue a bit more before you criticize people who has spent a great
deal of time trying to get a working solution.
Regards,
Brix
--
Henrik Brix Andersen <[email protected]>
Gentoo Metadistribution | Mobile computing herd
On Monday 20 February 2006 16:39, Olivier Galibert wrote:
> On Mon, Feb 20, 2006 at 03:13:23PM +0100, Rafael J. Wysocki wrote:
}-- snip --{
> From what I see of the messages in this thread, at that point you're
> just trying to play catchup with suspend2.
Well, I don't think I am. Or maybe a little. Still, are you trying to say that
GNOME developers should give up because KDE is more advanced in some
respects or vice versa?
> Don't that feel a little strange to you? You know you have working GPL code
> handy, tested with happy users, with a maintainer who would be happy to have
> it in the kernel, and instead of making it better you spend your talents redoing
> the same functionality only slightly differently. Why?
_I_ am doing it as a proof of concept. Many people said it didn't make sense
to implement this in the user space and that it wouldn't work, and it would
take ages to do this etc. I don't agree with that and I want to show I'm right.
Is that wrong?
> > > Right now it really looks like they're only
> > > trying to redo what's already in suspend2, tested and debugged, only
> > > different and new, hence untested and undebugged.
> >
> > Actually a lot of the code that we use _has_ _been_ tested and debugged,
> > because it _is_ used on a daily basis by many people, like eg.:
> > - MD5 from the coreutils package,
> > - libLZF (the original one)
> > (openSSL wil be used soon for the image encryption).
> >
> > And I'm not trying to redo suspend2 in the user space. Instead I'm trying
> > to use the code that's _already_ _available_ in the user space to obtain
> > the functionality that suspend2 implements in the kernel space.
>
> "obtaining the functionality that suspend2 implements" means "redoing
> suspend2".
No, it doesn't. By the same token you could say writing another mail
client is redoing Mozilla Thunderbird.
> Don't play on words, please.
I don't. I really _think_ it's not the same. :-)
> md5 is already in the kernel (twice). lzf is already in suspend2 (and
> arguably useful for more things than only suspending),
Now seriously. Nigel already _had_ submitted the LZF patch, but it
was not accepted by the cryptoAPI maintainers. Neither me, nor Pavel
took part in that. The same applies to many things in suspend2,
just browse the LKML archives for the record.
> so suspend2's implementation has been tested for use in a suspend context,
> while libLZF hasn't. You _will_ have bugs putting things together, that's a
> given.
You're probably right.
> Now explain me why you're tying together code from coreutils and other
> sources when you have the same code, only already tested in a suspend
> context (memory management, etc), in suspend2.
Sorry, it's not like that. The memory management is not done by the
userland part, it's done by the kernel. The role of the userland part
is to read the image from the kernel, transform it (compress/encrypt/whatever)
if needed and save to disk. All that.
> Why, for the image save, did you port the code from swsusp with for instance
> its lack of async i/o, instead of porting the suspend2 code?
Because suspend2 code is incompatible with what's in the kernel now.
To use the suspend2 code I'd have to modify the kernel code substantially, and
that's what Pavel didn't want. OTOH the swsusp code was known to work
and I used it to test the new code, too.
> > The problem is to merge suspend2 we'd have to clean it up first and
> > actually solve some problems that it works around. That, arguably,
> > would be more work than just implementing some _easy_ stuff in the
> > user space.
>
> Stuff that is _already_ _done_ and working.
Functionality-wise, your right. The problem is how it's done, I think, and
that is not so obvious.
> Be careful though, you're awfully close to saying that userspace code
> is easier because it isn't reviewed[1] while kernel code has higher
> standards.
Oh, come on. You can review it, everybody can. Moreover, you're welcome to
do this. :-)
}-- snip --{
> The constraints on userland suspend code are rather close to RT kernel
> code, so technically it would be a much better base.
Can you please tell me why do you think so?
> 4- why aren't you actively working at pushing the parts of suspend2
> that actually are good and potentially useful to uswsusp in the
> mainline kernel. Do you really think nothing is worthwhile in there?
Because there are no patches to work on? I'd _really_ love to work on patches
that modify the current kernel code _gradually_ instead of just trying to
replace it top-down with something else in one big shot.
For example, I'd really appreciate it if Nigel could prepare a patch against
the current -mm implementing the freezing of bdevs he was talking about,
and there are more things like that.
> Are you really, really sure you're not rejecting suspend2 in bulk
> because you didn't write it?
Oh, _I_ am not rejecting it. I've never said so. I just don't think there's
a chance it will be merged in the short run, for various reasons, so
I'm working on an alternative.
}-- snip --{
> Please tell me what is wrong in my perception of what is going on.
I think you are assuming I'm doing this to prevent suspend2 from being merged.
It is not so, as I've tried to explain above. If you don't accept my point of view,
I'll respect that.
Greetings,
Rafael
PS
I didn't write s2ram, so I can't comment your observations wrt it.
On Monday 20 February 2006 17:30, Dmitry Torokhov wrote:
> On 2/20/06, Rafael J. Wysocki <[email protected]> wrote:
> > On Monday 20 February 2006 16:08, Dmitry Torokhov wrote:
> > > On 2/20/06, Pavel Machek <[email protected]> wrote:
> > > > >
> > > > > I know I am bad for not reporting that earlier but swsusp was working
> > > > > OK for me till about 3 month ago when I started getting "soft lockup
> > > > > detected on CPU0" with no useable backtrace 3 times out of 4. I
> > > > > somehow suspect that having automounted nfs helps it to fail
> > > > > somehow...
> > > >
> > > > Disable soft lockup watchdog :-).
> > >
> > > Ok, I will try, but is this the permanent solution you are proposing?
> >
> > Certainly not.
> >
> > The problem is the soft lockup watchdog tends to produce false-positives
> > related to the clock resume vs timer interrupt dependencies that are
> > hard to trace.
> >
> > I used to get those on a regular basis until the timer resume on x86-64
> > got fixed a month ago or so.
> >
> > Please try the latest -mm and see if it's not fixed there. If not, please
> > file a bug report with bugzilla (with Cc to me).
> >
>
> Latest -mm is way too big a target. Do you have a specific patches in
> mind? Again my working kernel is based off tip of Linus's tree plus my
> patches, not -mm.
What architecture is it running on?
Rafael
On 2/20/06, Rafael J. Wysocki <[email protected]> wrote:
> On Monday 20 February 2006 17:30, Dmitry Torokhov wrote:
> >
> > Latest -mm is way too big a target. Do you have a specific patches in
> > mind? Again my working kernel is based off tip of Linus's tree plus my
> > patches, not -mm.
>
> What architecture is it running on?
>
i386, nothing fancy.
--
Dmitry
On Mon, Feb 20, 2006 at 04:27:24PM +0000, Andreas Happe wrote:
> through using the userspace helper he is able to use existing maintained
> libaries, something that isn't possible with kernelspace suspend. This
> is real code reduction.
The only thing that is said will be used by uswsusp that isn't already
in the kernel in lzf. md5 is there twice, crypto is there. lzf it
seems belongs in cryptoloop too according to some of the reactions.
> > md5 is already in the kernel (twice). lzf is already in suspend2 (and
> > arguably useful for more things than only suspending),
>
> Why (when LZF would be useful for other stuff) nobody proposed inclusion
> of it?
You missed all the messages of people who would like it in cryptoloop
for compressed filesystems? Part of the problem it seems with Nigel's
code is that it is stamped "suspend2", and nobody looks for useful
code in there.
> >> The problem is to merge suspend2 we'd have to clean it up first and
> >> actually solve some problems that it works around. That, arguably,
> >> would be more work than just implementing some _easy_ stuff in the
> >> user space.
> >
> > Stuff that is _already_ _done_ and working.
>
> While reading this 'discussion' I get the expression that swsusp isn't
> working. But this isn't true: it works for me since I can't remember
> when. The only problems were with some modules (ieee1394 had to be
> unloaded before suspending) and minor glinches (writing the image
> sometimes _very_ slow when suspending from a powersave cpufreq
> governor..).
It hasn't worked for me reliably on any of the dell laptops we have
around. Driver problem, irq problem, who knows. Pavel would sure
like to have these problems fixed, no doubt about that, but uswsusp
has nothing to do with fixing them. The entire point of uswsusp is to
have progress bars, compression and encryption. It has _nothing_ to
do with the reliability of suspend itself.
Suspend2 already has the progress bars and stuff. Hence the "already
done and working".
> > 1- will uswsusp solve problems suspend2 doesn't? Real, currently
> > encountered problems, not philosophical problems about
> > kernel/userspace code positions[2].
>
> swsusp works for me (TM), no problems at all, siree
That does not answer the question. If there are no problems with
swsusp, there is no need for either suspend2 or uswsusp.
> > In particular, since according
> > to Pavel 90+% of the problems are driver issues, why aren't you
> > concentrating on drivers?
>
> so submit driver specific patches through the driver's maintainer? Where
> does Pavel enter the picture?
Pavel is the swsusp maintainer. Pavel is the one defining the
interfaces drivers have to conform to to play ball. Quality and
documentation of these interfaces is what makes the difference when
you have to use them in the drivers.
At that point, with the last clash with Linus, I don't really know
what has to be done with IRQs in particular.
> > 3- if the main problem is really that some parts of suspend2 should be
> > in userspace instead of kernelspace, why aren't you working from the
> > appropriate parts of the suspend2 code to port them to userspace use
> > instead of going to coreutils/libLZF/etc?
>
> code dupplication?
Duplicating what? There are multiple implementations, some in
suspend2, some in libraries. The suspend2 ones, as kernel routines,
are designed to work in a constrained environment, fs, network and
memory-wise. The library ones aren't. Uswsusp needs code that works
in a constrained environment. So the technically clueful way is to
start from the libraries?
> > 4- why aren't you actively working at pushing the parts of suspend2
> > that actually are good and potentially useful to uswsusp in the
> > mainline kernel. Do you really think nothing is worthwhile in there?
>
> Maybe the mentioned problems with bitmaps and the module infrastructure
> could explain that. Even Nigel said that the problem with evolutionary
> patches is that suspend2 changes some fundamentals.
For some people, like you, swsusp works as-is. Good. For some more
people, swsusp doesn't work reliably, while suspend2 does. So there
are some things in suspend2 that are better than the current
implementation. I see zero effort to find out what these things are
> > Are you really, really sure you're not rejecting suspend2 in bulk
> > because you didn't write it? Do we need a John W. Linville as suspend
> > maintainer for things to go better?
>
> Are you really threatening Pavel's position as maintainer? how subtle.
Am I? I have _zero_ authority over who maintains what, you know. I
know that, Pavel knows that, Rafael knows that. And I never said
Pavel or Rafael were not competent, quite the contrary. I'm just
casting some doubt on their current methods. I don't like seeing
anymore throwing of the baby with the bathwater going on than strictly
necessary.
> > [2] Otherwise you can start net5 in userspace just because it doesn't
> > absolutely need to be in kernelspace.
>
> it seems like "Van Jacobson's network channels" [0] would move some
> stuff to userspace. Are you volunteering? (dislaimer: I have just
> glimpsed at the article).
>
> [0] http://lwn.net/Articles/169961/
Obviously not. I think networking belongs to the kernel, and moving
things to userspace because it somehow magically makes maintenance
easier is complete bullshit. I have criteria to decide what should be
in the kernel and what should be in userspace, and networking squarely
belongs in kernelspace.
OG.
On Mon, Feb 20, 2006 at 06:16:55PM +0100, Rafael J. Wysocki wrote:
> On Monday 20 February 2006 16:39, Olivier Galibert wrote:
> > On Mon, Feb 20, 2006 at 03:13:23PM +0100, Rafael J. Wysocki wrote:
> }-- snip --{
> > From what I see of the messages in this thread, at that point you're
> > just trying to play catchup with suspend2.
>
> Well, I don't think I am. Or maybe a little. Still, are you trying to say that
> GNOME developers should give up because KDE is more advanced in some
> respects or vice versa?
The GNOME/KDE situation is an interesting parallel. GNOME was created
as you probably know essentially because of licensing issues with Qt.
I suspect RedHat wanting to differentiate itself from Suse probably
helped justifying the financing. For a long while GNOME just played
catchup with KDE. Current situation is amusing, though. Sanity has
prevailed, applications are made interoperable between the two
environments and a modern desktop uses from the two indifferently.
There is slightly less duplication between the two, too. But at the
same time both desktops are trying very hard to differenciate from
each other, GNOME is playing the "user friendlyness" card for
instance, whatever their definition of that is.
Now here, we're talking about suspend. Something where the best user
interface is no user interface. Disk speeds and memory sizes being
what there are you have to somehow tell the user that yes, things are
still moving. But otherwise, there isn't much to do to differenciate
from each other. Some amusing features could be added, especially at
the interaction between suspend to ram and disk, but STR is even more
unreliable than STD so it's not going to happen any time soon.
> > Don't that feel a little strange to you? You know you have working GPL code
> > handy, tested with happy users, with a maintainer who would be happy to have
> > it in the kernel, and instead of making it better you spend your talents redoing
> > the same functionality only slightly differently. Why?
>
> _I_ am doing it as a proof of concept. Many people said it didn't make sense
> to implement this in the user space and that it wouldn't work, and it would
> take ages to do this etc. I don't agree with that and I want to show I'm right.
> Is that wrong?
Nothing wrong with that. Cool hacks are cool pretty much by
definition :-)
Now try another point of view. STD as currently in the kernel is
unreliable, and don't get me started about STR. Assume that you are
the suspend maintainer for the kernel (you are the co-maintainer at
that point in practice). As such, you should want STD/STR to be
reliable. As an engineer, tell me if you think uswsusp has a chance
to make STD/STR more reliable than the current situation.
> No, it doesn't. By the same token you could say writing another mail
> client is redoing Mozilla Thunderbird.
You have, say, xmh. You start working to make it look and act like
Thunderbird. Isn't that redoing Thunderbird, whatever the
implementation looks like at the end?
> > md5 is already in the kernel (twice). lzf is already in suspend2 (and
> > arguably useful for more things than only suspending),
>
> Now seriously. Nigel already _had_ submitted the LZF patch, but it
> was not accepted by the cryptoAPI maintainers. Neither me, nor Pavel
> took part in that. The same applies to many things in suspend2,
> just browse the LKML archives for the record.
I'll try to have a look. I'm curious for the reasons (we don't need
that vs. we need that but that code is crap).
> > Now explain me why you're tying together code from coreutils and other
> > sources when you have the same code, only already tested in a suspend
> > context (memory management, etc), in suspend2.
>
> Sorry, it's not like that. The memory management is not done by the
> userland part, it's done by the kernel. The role of the userland part
> is to read the image from the kernel, transform it (compress/encrypt/whatever)
> if needed and save to disk. All that.
If the memory usage of your userland part is not severely bounded you
may have annoying issues. Libraries inmy experience tend to be quite
liberal in their allocations.
> > Why, for the image save, did you port the code from swsusp with for instance
> > its lack of async i/o, instead of porting the suspend2 code?
>
> Because suspend2 code is incompatible with what's in the kernel now.
>
> To use the suspend2 code I'd have to modify the kernel code substantially, and
> that's what Pavel didn't want. OTOH the swsusp code was known to work
> and I used it to test the new code, too.
Ok. I wouldn't have thought writing the image could be that
different, but I definitively take your word for it.
> > Stuff that is _already_ _done_ and working.
>
> Functionality-wise, your right. The problem is how it's done, I think, and
> that is not so obvious.
Heh. It obviously has been way too long out of mainline. Pavel's
reviews being 90% "you should do all that in userspace" are a little
tiring after a while though.
> > The constraints on userland suspend code are rather close to RT kernel
> > code, so technically it would be a much better base.
>
> Can you please tell me why do you think so?
Well, from what I see (I can be very wrong mind you), the constraints are:
- no fs access at all
- careful with memory, you don't want to push things into swap once
the image is done
That's very RT-ish. And all that essentially without the kernel
protecting you from your errors.
> > 4- why aren't you actively working at pushing the parts of suspend2
> > that actually are good and potentially useful to uswsusp in the
> > mainline kernel. Do you really think nothing is worthwhile in there?
>
> Because there are no patches to work on? I'd _really_ love to work on patches
> that modify the current kernel code _gradually_ instead of just trying to
> replace it top-down with something else in one big shot.
>
> For example, I'd really appreciate it if Nigel could prepare a patch against
> the current -mm implementing the freezing of bdevs he was talking about,
> and there are more things like that.
Ok, that attitude I completely agree with.
> > Please tell me what is wrong in my perception of what is going on.
>
> I think you are assuming I'm doing this to prevent suspend2 from being merged.
> It is not so, as I've tried to explain above. If you don't accept my point of view,
> I'll respect that.
You're way saner about suspend2 than Pavel is.
OG.
On Monday 20 February 2006 18:33, Dmitry Torokhov wrote:
> On 2/20/06, Rafael J. Wysocki <[email protected]> wrote:
> > On Monday 20 February 2006 17:30, Dmitry Torokhov wrote:
> > >
> > > Latest -mm is way too big a target. Do you have a specific patches in
> > > mind? Again my working kernel is based off tip of Linus's tree plus my
> > > patches, not -mm.
> >
> > What architecture is it running on?
> >
>
> i386, nothing fancy.
OK, I'll try to figure out what exactly is wrong, but I'll need to set up an
i386 test bed for this purpose which will take a few days.
Greetings,
Rafael
On Mon, Feb 20, 2006 at 06:10:00PM +0100, Pavel Machek wrote:
> On Po 20-02-06 18:05:37, Olivier Galibert wrote:
> > On Mon, Feb 20, 2006 at 01:49:37PM +0100, Pavel Machek wrote:
> > > > > Yep, if you do it all in userspace, this vanishes. 340 lines down.
> > > >
> > > > And you gain? Let's try not to be too biased :).
> > >
> > > I gain 340 less lines to review. For me to review, for akpm to review,
> > > and for Linus to review. That's important.
> >
> > Pavel, if you mean that the userspace code will not be reviewed to
> > standards the kernel code is, kill uswsusp _NOW_ before it does too
> > much damage. Unreliable suspend eats filesystems for breakfast. The
> > other userspace components of the kernels services are either optional
> > (udev) or not that important (alsa).
>
> At least it will be only me reviewing it, and not akpm and Linus.
Ok, your answer was saying the contrary (that you wouldn't review it
either). Frankly, you may want akpm or Linus to do reviews of even
userspace code when appropriate, and others too like Al Viro. They
have a freakingly good eye at detecting crap code.
> suspend2 received no such review, and still people claim it is
> reliable.
Plain numbers. Just count the "suspend2 works for me which swsusp
doesn't". I doubt it's purely luck, even if simply moving code around
can change behaviours.
> "I wish they'd kill suspend2 project, it already did enough
> damage." (Half joking here, but suspend2 split user/development
> community, and that's not good).
Yes, that's annoying. But be careful, you seem to be automatically
rejecting everything Nigel at that point, or at least that's what it
looks like.
You do what you want, obivously, but I suspect your reviews of the
suspend2 code would be way more interesting if you accepted it's not
uswsusp. Right now, they look more religious/political than really
technical.
Can you try doing a review where you temporarily accept suspend2's
kernel/userspace separation in the background, and review the code as
is? That way you'll even have a chance to find out where the
differences in reliability are coming from.
OG.
On Po 20-02-06 19:16:57, Olivier Galibert wrote:
> On Mon, Feb 20, 2006 at 06:16:55PM +0100, Rafael J. Wysocki wrote:
> > On Monday 20 February 2006 16:39, Olivier Galibert wrote:
> > > On Mon, Feb 20, 2006 at 03:13:23PM +0100, Rafael J. Wysocki wrote:
> > > Stuff that is _already_ _done_ and working.
> >
> > Functionality-wise, your right. The problem is how it's done, I think, and
> > that is not so obvious.
>
> Heh. It obviously has been way too long out of mainline. Pavel's
> reviews being 90% "you should do all that in userspace" are a little
> tiring after a while though.
That does not make them wrong... having to review code that does not
need to be in kernel in the first place is tiring, too.
Feel free to review that code yourself, and clean it up with Nigel;
but it is useless as long as it contains stuff such as "press 'C' to
continue, or any other key to reboot".
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Po 20-02-06 19:31:36, Olivier Galibert wrote:
> On Mon, Feb 20, 2006 at 06:10:00PM +0100, Pavel Machek wrote:
> > On Po 20-02-06 18:05:37, Olivier Galibert wrote:
> > > On Mon, Feb 20, 2006 at 01:49:37PM +0100, Pavel Machek wrote:
> > suspend2 received no such review, and still people claim it is
> > reliable.
>
> Plain numbers. Just count the "suspend2 works for me which swsusp
> doesn't". I doubt it's purely luck, even if simply moving code around
> can change behaviours.
Well, people with broken swsusp tend to try suspend2... that's why you
see so many reports. if you merged suspend2 and dropped swsusp, it
would be the other way around.
> > "I wish they'd kill suspend2 project, it already did enough
> > damage." (Half joking here, but suspend2 split user/development
> > community, and that's not good).
>
> Yes, that's annoying. But be careful, you seem to be automatically
> rejecting everything Nigel at that point, or at least that's what it
> looks like.
I'm not rejecting _everything_ Nigel does, but I have seen very little
acceptable kernel patches from him.
> You do what you want, obivously, but I suspect your reviews of the
> suspend2 code would be way more interesting if you accepted it's not
> uswsusp. Right now, they look more religious/political than really
> technical.
Feel free to review suspend2 yourself. You are likely to find many
small issues, and Nigel is likely to fix them; but that's useless: as
long as big issues are not fixed, code is not suitable for mainline
merge.
(And it is going to be easier to do it in userspace using existing -mm
infrastructure then to clean suspend2 patches).
Feel free to review suspend.sf.net code if you want to help; testing
would be useful at this point, too.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Mon, 2006-02-20 at 15:54 +0100, Pavel Machek wrote:
> > I know I am bad for not reporting that earlier but swsusp was
> working
> > OK for me till about 3 month ago when I started getting "soft lockup
> > detected on CPU0" with no useable backtrace 3 times out of 4. I
> > somehow suspect that having automounted nfs helps it to fail
> > somehow...
>
> Disable soft lockup watchdog :-).
You do know that message is harmless and doesn't actually do anything
right? It's just warning you that the kernel allowed something to hog
the CPU without rescheduling for a LONG time.
Lee
On Mon, 2006-02-20 at 17:22 +0100, Rafael J. Wysocki wrote:
> Certainly not.
>
> The problem is the soft lockup watchdog tends to produce
> false-positives
> related to the clock resume vs timer interrupt dependencies that are
> hard to trace.
>
> I used to get those on a regular basis until the timer resume on
> x86-64
> got fixed a month ago or so.
So it's uncovering bugs, exactly as intended.
Lee
On Mon, Feb 20, 2006 at 08:12:42PM +0100, Henrik Brix Andersen wrote:
> > I'd love to have Nigel helping me and kernel, but he's not
> > interested. He wants suspend2 merged, he does not want better suspend
> > in kernel.
>
> If you made comments like that about me on a public mailing list I
> would feel it would be very difficult trying to cooperate with you.
>
> Please reconsider your public replies regarding this already delicate
> issue a bit more before you criticize people who has spent a great
> deal of time trying to get a working solution.
I'm going to have to second Henrik here. Pavel, there are times when
you are starting to sound almost as strident as our cdrecord "friend".
Maybe you feel you are in a power position because your code happened
to enter the kernel first, so you few you can have veto power over all
other contenders. It sometimes works that way, but only up to a
point. The fact of the matter is, Nigel code's *works* and swsusp has
been at best slow and painful and unreliable. And while your been
complaining about how swsusp2 has been splitting the user community
sounds suspiciously like the NetBSD folks complaining that Linux took
all over their user community -- never mind the fact that their
attitude for a long time was, "if you can't figure out how to
bootstrap NetBSD, you don't DESERVE to run our code"; in contrast, we
worked on making Linux easy to install (the original reason why I
implemented them ramdisk and boot floppy loader code was specifically
to make the user install experience easier).
When users report problems, Nigel tries to help them. He doesn't say,
"driver problem, not my problem", or "should be done in user space;
why don't you implement it". Is it any surprise he has a huge user
community?
- Ted
On Po 20-02-06 14:51:55, Theodore Ts'o wrote:
> On Mon, Feb 20, 2006 at 08:12:42PM +0100, Henrik Brix Andersen wrote:
> > > I'd love to have Nigel helping me and kernel, but he's not
> > > interested. He wants suspend2 merged, he does not want better suspend
> > > in kernel.
> >
> > If you made comments like that about me on a public mailing list I
> > would feel it would be very difficult trying to cooperate with you.
> >
> > Please reconsider your public replies regarding this already delicate
> > issue a bit more before you criticize people who has spent a great
> > deal of time trying to get a working solution.
>
> I'm going to have to second Henrik here. Pavel, there are times when
> you are starting to sound almost as strident as our cdrecord
> "friend".
Heh, I hope I'm not that bad.
> Maybe you feel you are in a power position because your code happened
> to enter the kernel first, so you few you can have veto power over all
> other contenders. It sometimes works that way, but only up to a
Unfortunately, I do not need to veto suspend2. It is so complex that
it vetoes itself. Last time akpm stopped it, IIRC.
You are welcome to take a look at those patches and try to get them
into suitable form. But please don't compare me with Joerg unless you
seen the patches.
> point. The fact of the matter is, Nigel code's *works* and swsusp has
> been at best slow and painful and unreliable. And while your been
Painful and unreliable? Yep, it slow, at least it does not make rest
of kernel slower. We are adressing "slow" with uswsusp...
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Monday 20 February 2006 20:45, Lee Revell wrote:
> On Mon, 2006-02-20 at 15:54 +0100, Pavel Machek wrote:
> > > I know I am bad for not reporting that earlier but swsusp was
> > working
> > > OK for me till about 3 month ago when I started getting "soft lockup
> > > detected on CPU0" with no useable backtrace 3 times out of 4. I
> > > somehow suspect that having automounted nfs helps it to fail
> > > somehow...
> >
> > Disable soft lockup watchdog :-).
>
> You do know that message is harmless and doesn't actually do anything
> right? It's just warning you that the kernel allowed something to hog
> the CPU without rescheduling for a LONG time.
This particular one is almost certainly a false-positive. Still it doesn't
mean we shouldn't try to get rid of it.
Greetings,
Rafael
On 2/20/06, Lee Revell <[email protected]> wrote:
> On Mon, 2006-02-20 at 15:54 +0100, Pavel Machek wrote:
> > > I know I am bad for not reporting that earlier but swsusp was
> > working
> > > OK for me till about 3 month ago when I started getting "soft lockup
> > > detected on CPU0" with no useable backtrace 3 times out of 4. I
> > > somehow suspect that having automounted nfs helps it to fail
> > > somehow...
> >
> > Disable soft lockup watchdog :-).
>
> You do know that message is harmless and doesn't actually do anything
> right? It's just warning you that the kernel allowed something to hog
> the CPU without rescheduling for a LONG time.
Well, if that is harmless I am not sure what you'd call harmful ;)
because right after this message the box hangs solid and I have to
push and hold power button to power it off and start again.
--
Dmitry
On Monday 20 February 2006 19:16, Olivier Galibert wrote:
> On Mon, Feb 20, 2006 at 06:16:55PM +0100, Rafael J. Wysocki wrote:
> > On Monday 20 February 2006 16:39, Olivier Galibert wrote:
> > > On Mon, Feb 20, 2006 at 03:13:23PM +0100, Rafael J. Wysocki wrote:
}-- snip --{
> Now try another point of view. STD as currently in the kernel is
> unreliable,
It works for me 100% of the time, as of 2.6.16-rc4, so this statement is
too general, I think.
Besides, some important fixes are in -mm waiting for the 2.6.17 merging
window.
> and don't get me started about STR. Assume that you are
> the suspend maintainer for the kernel (you are the co-maintainer at
> that point in practice). As such, you should want STD/STR to be
> reliable. As an engineer, tell me if you think uswsusp has a chance
> to make STD/STR more reliable than the current situation.
Of course it doesn't, but the same applies to suspend2. It's not about
fixing driver problems etc. It's all about checkpointing the system and
saving the image (w/ some fancy transformations like encryption/compression).
[The suspend2 patch does contain driver fixes, but they really should be
posted separately or forwarded to the respective driver maintainers
(it's already happened, AFAICT). Please do not count the driver fixes as an
advantage of suspend2.]
Now there are two differences that may cause suspend2 to work where swsusp
doesn't: (1) suspend2 is able to free more memory during suspend, and
(2) suspend2 contains some code for freezing processes that is not
present in the mainline swsusp.
Let's consider (2) first. The freezing of processes in swsusp has recently
been improved so that it can freeze processes under _heavy_ load
and it's been done in much simpler way than suspend2 does it (this
patch is now in -mm). This code may be further improved by
porting the freezing of bdevs from suspend2, but that's not critical in
my view. OTOH this part of suspend2 contains at least one thing
that was rejected about 1 year ago and not by me or Pavel.
Now as far as (1) is concerned, there is a question if the way in which
that is done in suspend2 is really optimal. That will have to be considered
for a while and by people who know the kernel internals much better than I do.
> > No, it doesn't. By the same token you could say writing another mail
> > client is redoing Mozilla Thunderbird.
>
> You have, say, xmh. You start working to make it look and act like
> Thunderbird. Isn't that redoing Thunderbird, whatever the
> implementation looks like at the end?
Well, I don't want it to look and act like suspend2. I'd like it to provide
comparable functionality, in a different way.
}-- snip --{
> If the memory usage of your userland part is not severely bounded you
> may have annoying issues. Libraries inmy experience tend to be quite
> liberal in their allocations.
It isn't all that bad, apparently. So far I haven't experienced any problems
related to that.
}-- snip --{
> > Functionality-wise, your right. The problem is how it's done, I think, and
> > that is not so obvious.
>
> Heh. It obviously has been way too long out of mainline. Pavel's
> reviews being 90% "you should do all that in userspace" are a little
> tiring after a while though.
Well, I can't speak for Pavel.
> > > The constraints on userland suspend code are rather close to RT kernel
> > > code, so technically it would be a much better base.
> >
> > Can you please tell me why do you think so?
>
> Well, from what I see (I can be very wrong mind you), the constraints are:
> - no fs access at all
> - careful with memory, you don't want to push things into swap once
> the image is done
The second one should be safe, I think (the image reflects the state of swap
from before the "atomic snapshot" operation, so what happens to the
swap afterwards doesn't really matter).
> That's very RT-ish. And all that essentially without the kernel
> protecting you from your errors.
You're not so time-constrained, though, and there are no other threads
to worry about. :-)
Greetings,
Rafael
On Monday 20 February 2006 21:15, Dmitry Torokhov wrote:
> On 2/20/06, Lee Revell <[email protected]> wrote:
> > On Mon, 2006-02-20 at 15:54 +0100, Pavel Machek wrote:
> > > > I know I am bad for not reporting that earlier but swsusp was
> > > working
> > > > OK for me till about 3 month ago when I started getting "soft lockup
> > > > detected on CPU0" with no useable backtrace 3 times out of 4. I
> > > > somehow suspect that having automounted nfs helps it to fail
> > > > somehow...
> > >
> > > Disable soft lockup watchdog :-).
> >
> > You do know that message is harmless and doesn't actually do anything
> > right? It's just warning you that the kernel allowed something to hog
> > the CPU without rescheduling for a LONG time.
>
> Well, if that is harmless I am not sure what you'd call harmful ;)
> because right after this message the box hangs solid and I have to
> push and hold power button to power it off and start again.
Now this means you get the "softlockup watchdog" message because of a bug that
hangs your box and is actually detected by the watchdog. I didn't realize
that before, so please disregard my previous messages.
Have you tried to boot the box with "init=/bin/bash" and suspend? [You'll have
to mount /proc and /sys, and do "swapon -a" manually before
"echo disk > /sys/power/state".]
Greetings,
Rafael
Hi Dimitry.
On Tuesday 21 February 2006 00:01, Dmitry Torokhov wrote:
> On 2/20/06, Lee Revell <[email protected]> wrote:
> > On Mon, 2006-02-20 at 10:39 +0100, Matthias Hensler wrote:
> > > > It is slightly slower,
> > >
> > > Sorry, but that is just unacceptable.
> >
> > Um... suspend2 puts extra tests into really hot paths like fork(), which
> > is equally unacceptable to many people.
>
> How bad is it really? From what I saw marking that swsuspend2 branch
> with "unlikely" should help the hot path.
>
> > Why can't people understand that arguing "it works" without any
> > consideration of possible performance tradeoffs is not a good enough
> > argument for merging?
>
> Many of Pavel's arguments are not about performance tradeoffs but
> about perceived complexity of the code. I think if Nigel could run a
> clean up on his implementation and split it into couple of largish
> (not for inclusion but for general overview) pieces, like separate
> arch support, generally useful bits and the rest it would allow seeing
> more clearly how big and invasive swsuspend2 core is.
I'm working on doing that right now. I was starting on it with the plugins
patches a few weeks ago, and intended to follow it up pretty quickly with the
rest. Unfortunately I've gotten sidetracked and overwhelmed by email :) and a
lot of other things, so it's taking a lot longer than I wanted.
Never-the-less, I'm working towards precisely this.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On Po 20-02-06 21:08:07, Pavel Machek wrote:
> On Po 20-02-06 14:51:55, Theodore Ts'o wrote:
> > On Mon, Feb 20, 2006 at 08:12:42PM +0100, Henrik Brix Andersen wrote:
> > > > I'd love to have Nigel helping me and kernel, but he's not
> > > > interested. He wants suspend2 merged, he does not want better suspend
> > > > in kernel.
> > >
> > > If you made comments like that about me on a public mailing list I
> > > would feel it would be very difficult trying to cooperate with you.
> > >
> > > Please reconsider your public replies regarding this already delicate
> > > issue a bit more before you criticize people who has spent a great
> > > deal of time trying to get a working solution.
> >
> > I'm going to have to second Henrik here. Pavel, there are times when
> > you are starting to sound almost as strident as our cdrecord
> > "friend".
>
> Heh, I hope I'm not that bad.
>
> > Maybe you feel you are in a power position because your code happened
> > to enter the kernel first, so you few you can have veto power over all
> > other contenders. It sometimes works that way, but only up to a
>
> Unfortunately, I do not need to veto suspend2. It is so complex that
> it vetoes itself. Last time akpm stopped it, IIRC.
...BTW... here's how you could help. Part of the problem is that Nigel
does not trust me. When I tell him that something is not acceptable
for kernel, he tends to ignore it (probably thinking it is me hating
his code or something like that).
If you could take a look at the patches before they go to me, and
either tell him what is wrong with them, or tell me that you consider
them okay... I guess that would help a lot.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Mon, 2006-02-20 at 15:15 -0500, Dmitry Torokhov wrote:
> Well, if that is harmless I am not sure what you'd call harmful ;)
> because right after this message the box hangs solid and I have to
> push and hold power button to power it off and start again.
>
I don't think the watchdog does this. Probably the machine would have
locked up anyway. If you disable the watchdog does the machine keep
going?
Lee
Hi.
On Tuesday 21 February 2006 06:08, Pavel Machek wrote:
> > Maybe you feel you are in a power position because your code happened
> > to enter the kernel first, so you few you can have veto power over all
> > other contenders. It sometimes works that way, but only up to a
>
> Unfortunately, I do not need to veto suspend2. It is so complex that
> it vetoes itself. Last time akpm stopped it, IIRC.
I'm going to let most of the last 8 hours' emails float by without reply, but
think I should comment here.
I don't believe I've ever seen an email from Andrew stopping a merge, and I
shouldn't have, because I've never asked him to merge it. Being the
perfectionist that I am, I've sought to get it as stable, reliable and
comment-clean as I reasonably could before merging.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On ?t 21-02-06 06:44:34, Nigel Cunningham wrote:
> Hi.
>
> On Tuesday 21 February 2006 06:08, Pavel Machek wrote:
> > > Maybe you feel you are in a power position because your code happened
> > > to enter the kernel first, so you few you can have veto power over all
> > > other contenders. It sometimes works that way, but only up to a
> >
> > Unfortunately, I do not need to veto suspend2. It is so complex that
> > it vetoes itself. Last time akpm stopped it, IIRC.
>
> I'm going to let most of the last 8 hours' emails float by without reply, but
> think I should comment here.
Thanks.
> I don't believe I've ever seen an email from Andrew stopping a merge, and I
> shouldn't have, because I've never asked him to merge it. Being the
> perfectionist that I am, I've sought to get it as stable, reliable and
> comment-clean as I reasonably could before merging.
I believe I seen reply to that effect (saying "it is working and fast
is not enough for merge", or something like that.
Anyway, please Cc me on merge attempts...
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi.
On Tuesday 21 February 2006 06:59, Pavel Machek wrote:
> > I don't believe I've ever seen an email from Andrew stopping a merge, and
> > I shouldn't have, because I've never asked him to merge it. Being the
> > perfectionist that I am, I've sought to get it as stable, reliable and
> > comment-clean as I reasonably could before merging.
>
> I believe I seen reply to that effect (saying "it is working and fast
> is not enough for merge", or something like that.
>
> Anyway, please Cc me on merge attempts...
Ah. So maybe it wasn't in response to a direct request from me. Okay.
With regard to real attempts, I'll be submitting the remainder for review soon
(DV). I won't cc you then since you'll see it on LKML anyway. Don't take that
as an attempt.
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
On 2006-02-20, Olivier Galibert <[email protected]> wrote:
> On Mon, Feb 20, 2006 at 04:27:24PM +0000, Andreas Happe wrote:
>> Why (when LZF would be useful for other stuff) nobody proposed inclusion
>> of it?
>
> You missed all the messages of people who would like it in cryptoloop
> for compressed filesystems?
then why isn't it in mainline then?
> Part of the problem it seems with Nigel's code is that it is stamped
> "suspend2", and nobody looks for useful code in there.
I seem to remember critisims of various aspects of the suspend2 patch
(bitmaps etc., and those were not from neither Pavel or Rafael).
> It hasn't worked for me reliably on any of the dell laptops we have
> around. Driver problem, irq problem, who knows. Pavel would sure
> like to have these problems fixed, no doubt about that, but uswsusp
> has nothing to do with fixing them.
And the answer to your bug reports were?
> The entire point of uswsusp is to have progress bars, compression and
> encryption. It has _nothing_ to do with the reliability of suspend
> itself.
Well.. progress bars, compression and encryption are the advantages that
suspend2 seems to have over swsusp in my current situation. (encryption
somewhat dances out of line as this was already supported by swsusp).
> Suspend2 already has the progress bars and stuff. Hence the "already
> done and working".
I do not really care about that stuff, swsusp works reliable for me. If
it crashes for you maybe some bug reports or even debugging would be way
more productive than those endless 'swsusp vs suspend2' debates.
>> > 1- will uswsusp solve problems suspend2 doesn't? Real, currently
>> > encountered problems, not philosophical problems about
>> > kernel/userspace code positions[2].
>>
>> swsusp works for me (TM), no problems at all, siree
>
> That does not answer the question. If there are no problems with
> swsusp, there is no need for either suspend2 or uswsusp.
couldn't be stated clearer. Remember that only the users for which
swsusp doesn't work will state their problems (or those that want more
bling).
Although there seems to be a need for bling and encryption which can
perfectly done in userspace (compare that to bootsplash vs. usplash).
>> so submit driver specific patches through the driver's maintainer?
>> Where does Pavel enter the picture?
>
> Pavel is the swsusp maintainer. Pavel is the one defining the
> interfaces drivers have to conform to to play ball. Quality and
> documentation of these interfaces is what makes the difference when
> you have to use them in the drivers.
I thought that those driver changes would mostly be power mgmt changes..
that would the existing infrastructure (i.e. maintained by Patrick
Mochel).
>> > 3- if the main problem is really that some parts of suspend2 should
>> > be in userspace instead of kernelspace, why aren't you working from
>> > the appropriate parts of the suspend2 code to port them to
>> > userspace use instead of going to coreutils/libLZF/etc?
>>
>> code dupplication?
>
> Duplicating what? There are multiple implementations, some in
> suspend2, some in libraries. The suspend2 ones, as kernel routines,
> are designed to work in a constrained environment, fs, network and
> memory-wise. The library ones aren't. Uswsusp needs code that works
> in a constrained environment. So the technically clueful way is to
> start from the libraries?
libraries will be used by more people -> more testing and bug fixes (for
'free'). The constraints should relate to hard disk/hardware activity?
memory usage shouldn't be that much of a problem (and the userspace
parts are used for transformations.. and if you can't trust in a working
libopenssl.. you're already hosed).
> For some people, like you, swsusp works as-is. Good. For some more
> people, swsusp doesn't work reliably, while suspend2 does. So there
> are some things in suspend2 that are better than the current
> implementation.
I think that 'some people, like you' may be more than you think.
I tried to use suspend2, but setup wasn't that great (i.e. didn't work
as well or easy as swsusp) so I dropped it.
> I see zero effort to find out what these things are
Than pray do it. I think patches would be welcomed.
> I don't like seeing anymore throwing of the baby with the bathwater
> going on than strictly necessary.
So you think the maintainer to be competent but you don't believe they
got valid technical reasons to deny those patches? Have you seen the
module support for suspend thread? or the bitmap thread? Those were not
simple problems.
> Obviously not. I think networking belongs to the kernel, and moving
> things to userspace because it somehow magically makes maintenance
> easier is complete bullshit. I have criteria to decide what should be
> in the kernel and what should be in userspace, and networking squarely
> belongs in kernelspace.
Encryption and compression for non-timecritical tasks: User or
kernelspace? The other stuff would be driver fixes (which would be
accepted) or infrastructure changes (rafael is at least interested in
bdev freezing, other stuff like using bitmaps seem totaly not acceptable
(and weren't for rather long.. but nigel didn't seem to mind)).
[BTW: the network stuff was about performance (reduced code
complexitivity was just a side effect). Maintenance isn't easier, but
the chances that you totally fsck up a system is smaller in userspace
than in kernel space).
Andy
Hi.
On Tuesday 21 February 2006 10:52, Andreas Happe wrote:
[...]
> I think that 'some people, like you' may be more than you think.
>
> I tried to use suspend2, but setup wasn't that great (i.e. didn't work
> as well or easy as swsusp) so I dropped it.
Could you provide more detail? If there's something I can do to make it easier
to use, I'm more than willing to consider that.
[...]
> Encryption and compression for non-timecritical tasks: User or
> kernelspace? The other stuff would be driver fixes (which would be
> accepted) or infrastructure changes (rafael is at least interested in
> bdev freezing, other stuff like using bitmaps seem totaly not acceptable
> (and weren't for rather long.. but nigel didn't seem to mind)).
I'm not sure I get what you're saying I didn't seem to mind.
Your comment about using bitmaps made me do some math to see how much I'm
saving by using them instead of Pavel's struct pbes. I don't think they were
commented on as 'totally unacceptable', but as I look at them again now, I'm
not so sure they're worth the effort. Will look again a little later in the
day, particularly at the flow on effects of making such a change - perhaps
I've forgotten something else).
(For the record, my thinking went: swsusp uses n (12?) bytes of meta data for
every page you save, where as using bitmaps makes that much closer to a
constant value (a small variable amount for recording where the image will be
stored in extents). 12 bytes per page is 3MB/1GB. If swsusp was to add
support for multiple swap partitions or writing to files, those requirements
might be closer to 5MB/GB. Bitmaps, in comparison, use ~32K/GB (approx
because it depends whether the gigabyte is all in one zone). Proportionally,
bitmaps are eating a lot less space out of your gigabyte, but I don't think
anyone is going to notice that they have 3 or 4MB more cache per gigabyte
with Suspend2 than they have with swsusp).
Regards,
Nigel
On Monday 20 February 2006 21:57, Nigel Cunningham wrote:
> For the record, my thinking went: swsusp uses n (12?) bytes of meta data for
> every page you save, where as using bitmaps makes that much closer to a
> constant value (a small variable amount for recording where the image will be
> stored in extents). 12 bytes per page is 3MB/1GB. If swsusp was to add
> support for multiple swap partitions or writing to files, those requirements
> might be closer to 5MB/GB.
5MB/GB amounts to 0.5% overhead, I don't think you should be concerned here.
Much more important IMHO is that IIRC swsusp requires to be able to free 1/2
of the physical memory whuch is hard on low memory boxes.
--
Dmitry
Matthias Hensler wrote:
> Hi.
>
> On Mon, Feb 20, 2006 at 01:53:33AM +0100, Pavel Machek wrote:
>
>>Only feature I can't do is "save whole pagecache"... and 14000 lines
>>of code for _that_ is a bit too much. I could probably patch my kernel
>>to dump pagecache to userspace, but I do not think it is worth the
>>effort.
>
>
> I do not think that Suspend 2 needs 14000 lines for that, the core is
> much smaller. But besides, _not_ saving the pagecache is a really _bad_
> idea. I expect to have my system back after resume, in the same state I
> had left it prior to suspend. I really do not like it how it is done by
> Windows, it is just ugly to have a slowly responding system after
> resume, because all caches and buffers are gone.
>
> I can only speak for myself, but I want to work with my system from the
> moment my desktop is back.
I Am Not A VM Hacker, but:
What's the point of saving pagecache during suspend? This seems like a
total waste. Why don't we save a list of pages in pagecache to disk,
then, after resume, prefetch them all back in. This will slow down
resume (extra seeks, minimized if we sort the list, and inability
to compress these pages), but it will speed up suspend, and it sounds
a lot simpler. There's already a patch to add swap prefetching, and
this can't be much more complicated.
While I'm at it, here's another pie-in-the-sky idea. If we had the
ability to unmount an in-use filesystem (that lack is my single biggest
pet peeve about Linux right now -- Windows has been able to do this for
ages), then the process could be:
1. Atomic snapshot of userspace. Snapshot all struct file's as well.
2. Unmount local filesystems. Network filesystems probably can't be
trashed by buggy suspend anyway.
3. Snapshot kernelspace.
4. Suspend happily without worrying about hosing filesystems, since
they're all unmounted.
5. For extra safety, unmount anything that the suspend process mounted.
-- Shutdown and restart --
6. Mount stuff and load the image, then unmount it (again using the
in-use FS unmounting).
7. Restore the image and resume kernelspace.
8. Remount local filesystems and reattach all the struct files.
9. Resume userspace. Start prefetching everything.
This would seem to allow an ordinary program to handle image writing
with no particular worries about disk access, except that unlinking
files might confuse userspace (but not the FS) on resume.
Feel free to tell me why this is impossible. If no one tells me it's
impossible, I may work on unmounting in-use filesystems and revoking
fd's in a month when I have more free time.
--Andy
Hi Andy.
On Tuesday 21 February 2006 14:32, Andy Lutomirski wrote:
> Matthias Hensler wrote:
> > Hi.
> >
> > On Mon, Feb 20, 2006 at 01:53:33AM +0100, Pavel Machek wrote:
> >>Only feature I can't do is "save whole pagecache"... and 14000 lines
> >>of code for _that_ is a bit too much. I could probably patch my kernel
> >>to dump pagecache to userspace, but I do not think it is worth the
> >>effort.
> >
> > I do not think that Suspend 2 needs 14000 lines for that, the core is
> > much smaller. But besides, _not_ saving the pagecache is a really _bad_
> > idea. I expect to have my system back after resume, in the same state I
> > had left it prior to suspend. I really do not like it how it is done by
> > Windows, it is just ugly to have a slowly responding system after
> > resume, because all caches and buffers are gone.
> >
> > I can only speak for myself, but I want to work with my system from the
> > moment my desktop is back.
>
> I Am Not A VM Hacker, but:
>
> What's the point of saving pagecache during suspend? This seems like a
> total waste. Why don't we save a list of pages in pagecache to disk,
> then, after resume, prefetch them all back in. This will slow down
> resume (extra seeks, minimized if we sort the list, and inability
> to compress these pages), but it will speed up suspend, and it sounds
> a lot simpler. There's already a patch to add swap prefetching, and
> this can't be much more complicated.
The page cache contains the process pages, among other things, so it can't all
be discarded with impunity. You're right in suggesting that discarding them
and then prefetching them would be a potential alternative, but it would
actually be more complicated: you'd still have to remember which pages you
wanted to fault back in, and some how store that info in the image. You'd
also have to add code to do the faulting. Right now, we don't (for the most
part) care what a page is used for - we just save and reload it. I believe
both implementations give you the option to set a soft upper limit on the
size of the image, so you can still throw away cache if you want to.
> While I'm at it, here's another pie-in-the-sky idea. If we had the
> ability to unmount an in-use filesystem (that lack is my single biggest
> pet peeve about Linux right now -- Windows has been able to do this for
> ages), then the process could be:
> 1. Atomic snapshot of userspace. Snapshot all struct file's as well.
> 2. Unmount local filesystems. Network filesystems probably can't be
> trashed by buggy suspend anyway.
> 3. Snapshot kernelspace.
> 4. Suspend happily without worrying about hosing filesystems, since
> they're all unmounted.
> 5. For extra safety, unmount anything that the suspend process mounted.
>
> -- Shutdown and restart --
>
> 6. Mount stuff and load the image, then unmount it (again using the
> in-use FS unmounting).
> 7. Restore the image and resume kernelspace.
> 8. Remount local filesystems and reattach all the struct files.
> 9. Resume userspace. Start prefetching everything.
>
> This would seem to allow an ordinary program to handle image writing
> with no particular worries about disk access, except that unlinking
> files might confuse userspace (but not the FS) on resume.
>
> Feel free to tell me why this is impossible. If no one tells me it's
> impossible, I may work on unmounting in-use filesystems and revoking
> fd's in a month when I have more free time.
It's not quite unmounting, but Suspend2 already freezes bdevs as part of the
process of quiescing the system. This was the only way I could find to make
XFS really complete pending I/O (and stop further submissions).
Regards,
Nigel
--
See our web page for Howtos, FAQs, the Wiki and mailing list info.
http://www.suspend2.net IRC: #suspend2 on Freenode
Hi.
On Tuesday 21 February 2006 14:19, Dmitry Torokhov wrote:
> On Monday 20 February 2006 21:57, Nigel Cunningham wrote:
> > For the record, my thinking went: swsusp uses n (12?) bytes of meta data
> > for every page you save, where as using bitmaps makes that much closer to
> > a constant value (a small variable amount for recording where the image
> > will be stored in extents). 12 bytes per page is 3MB/1GB. If swsusp was
> > to add support for multiple swap partitions or writing to files, those
> > requirements might be closer to 5MB/GB.
>
> 5MB/GB amounts to 0.5% overhead, I don't think you should be concerned
> here. Much more important IMHO is that IIRC swsusp requires to be able to
> free 1/2 of the physical memory whuch is hard on low memory boxes.
Agreed. I'll look for related issues, and if there are none (or nothing
serious), we can have one less difference between the two implementations. I
may even be able to share the lowlevel code with Pavel then. That would be a
good step forward.
Regards,
Nigel
On Po 20-02-06 20:32:25, Andy Lutomirski wrote:
> Matthias Hensler wrote:
> >Hi.
> >
> >On Mon, Feb 20, 2006 at 01:53:33AM +0100, Pavel Machek wrote:
> >
> >>Only feature I can't do is "save whole pagecache"... and 14000 lines
> >>of code for _that_ is a bit too much. I could probably patch my kernel
> >>to dump pagecache to userspace, but I do not think it is worth the
> >>effort.
> >
> >
> >I do not think that Suspend 2 needs 14000 lines for that, the core is
> >much smaller. But besides, _not_ saving the pagecache is a really _bad_
> >idea. I expect to have my system back after resume, in the same state I
> >had left it prior to suspend. I really do not like it how it is done by
> >Windows, it is just ugly to have a slowly responding system after
> >resume, because all caches and buffers are gone.
> >
> >I can only speak for myself, but I want to work with my system from the
> >moment my desktop is back.
>
> I Am Not A VM Hacker, but:
>
> What's the point of saving pagecache during suspend? This seems like a
> total waste. Why don't we save a list of pages in pagecache to disk,
> then, after resume, prefetch them all back in. This will slow down
> resume (extra seeks, minimized if we sort the list, and inability
> to compress these pages), but it will speed up suspend, and it sounds
> a lot simpler. There's already a patch to add swap prefetching, and
> this can't be much more complicated.
I'd actually love to see this implemented. It would be useful for
suspend-to-disk (obviously), but also for benchmarks.
> While I'm at it, here's another pie-in-the-sky idea. If we had the
Yes, that's quite far in the sky :-).
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi!
> > > I can only speak for myself, but I want to work with my system from the
> > > moment my desktop is back.
> >
> > I Am Not A VM Hacker, but:
> >
> > What's the point of saving pagecache during suspend? This seems like a
> > total waste. Why don't we save a list of pages in pagecache to disk,
> > then, after resume, prefetch them all back in. This will slow down
> > resume (extra seeks, minimized if we sort the list, and inability
> > to compress these pages), but it will speed up suspend, and it sounds
> > a lot simpler. There's already a patch to add swap prefetching, and
> > this can't be much more complicated.
>
> The page cache contains the process pages, among other things, so it can't all
> be discarded with impunity. You're right in suggesting that
> discarding them
Well, we already have perfectly good code to free pagecache.
> and then prefetching them would be a potential alternative, but it would
> actually be more complicated: you'd still have to remember which pages you
> wanted to fault back in, and some how store that info in the
> image. You'd
That's okay. Imagine
"cat /proc/vm/pagecache-contents > /tmp/delme" just before suspend and
"cat /tmp/delme | prefetcher" just after it. Prefetcher is actually
simple app that reads specified pages, then discards them. It can
actually be done in userspace around regular swsusp/uswsusp/suspend2
with no impact on it.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On ?t 21-02-06 15:51:08, Nigel Cunningham wrote:
> Hi.
>
> On Tuesday 21 February 2006 14:19, Dmitry Torokhov wrote:
> > On Monday 20 February 2006 21:57, Nigel Cunningham wrote:
> > > For the record, my thinking went: swsusp uses n (12?) bytes of meta data
> > > for every page you save, where as using bitmaps makes that much closer to
> > > a constant value (a small variable amount for recording where the image
> > > will be stored in extents). 12 bytes per page is 3MB/1GB. If swsusp was
> > > to add support for multiple swap partitions or writing to files, those
> > > requirements might be closer to 5MB/GB.
> >
> > 5MB/GB amounts to 0.5% overhead, I don't think you should be concerned
> > here. Much more important IMHO is that IIRC swsusp requires to be able to
> > free 1/2 of the physical memory whuch is hard on low memory boxes.
>
> Agreed. I'll look for related issues, and if there are none (or nothing
> serious), we can have one less difference between the two implementations. I
> may even be able to share the lowlevel code with Pavel then. That would be a
> good step forward.
Yep, that would be very nice.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi,
On Tuesday 21 February 2006 12:33, Pavel Machek wrote:
> On Po 20-02-06 20:32:25, Andy Lutomirski wrote:
> > Matthias Hensler wrote:
> > >On Mon, Feb 20, 2006 at 01:53:33AM +0100, Pavel Machek wrote:
> > >
> > >>Only feature I can't do is "save whole pagecache"... and 14000 lines
> > >>of code for _that_ is a bit too much. I could probably patch my kernel
> > >>to dump pagecache to userspace, but I do not think it is worth the
> > >>effort.
> > >
> > >
> > >I do not think that Suspend 2 needs 14000 lines for that, the core is
> > >much smaller. But besides, _not_ saving the pagecache is a really _bad_
> > >idea. I expect to have my system back after resume, in the same state I
> > >had left it prior to suspend. I really do not like it how it is done by
> > >Windows, it is just ugly to have a slowly responding system after
> > >resume, because all caches and buffers are gone.
> > >
> > >I can only speak for myself, but I want to work with my system from the
> > >moment my desktop is back.
> >
> > I Am Not A VM Hacker, but:
> >
> > What's the point of saving pagecache during suspend? This seems like a
> > total waste. Why don't we save a list of pages in pagecache to disk,
> > then, after resume, prefetch them all back in. This will slow down
> > resume (extra seeks, minimized if we sort the list, and inability
> > to compress these pages), but it will speed up suspend, and it sounds
> > a lot simpler. There's already a patch to add swap prefetching, and
> > this can't be much more complicated.
>
> I'd actually love to see this implemented. It would be useful for
> suspend-to-disk (obviously), but also for benchmarks.
Actually I've been thinking of something similar for some time,
so perhaps we should add this to the todolist somewhere? ;-)
Rafael
On Tuesday 21 February 2006 05:19, Dmitry Torokhov wrote:
> On Monday 20 February 2006 21:57, Nigel Cunningham wrote:
> > For the record, my thinking went: swsusp uses n (12?) bytes of meta data for
> > every page you save, where as using bitmaps makes that much closer to a
> > constant value (a small variable amount for recording where the image will be
> > stored in extents). 12 bytes per page is 3MB/1GB. If swsusp was to add
> > support for multiple swap partitions or writing to files, those requirements
> > might be closer to 5MB/GB.
>
> 5MB/GB amounts to 0.5% overhead, I don't think you should be concerned here.
> Much more important IMHO is that IIRC swsusp requires to be able to free 1/2
> of the physical memory whuch is hard on low memory boxes.
I see another point in using bitmaps: we could avoid modifying page flags
and use bitmaps to store all of the temporary information. I thought about
it for some time and I think it's doable.
Greetings,
Rafael
On Mon, 2006-02-20 at 18:05 +0100, Olivier Galibert wrote:
> Pavel, if you mean that the userspace code will not be reviewed to
> standards the kernel code is, kill uswsusp _NOW_ before it does too
> much damage. Unreliable suspend eats filesystems for breakfast. The
> other userspace components of the kernels services are either optional
> (udev) or not that important (alsa).
>
Why is sound less important than suspending, or networking, or any other
subsystem? This is an insult to everyone who worked long and hard to
get decent sound support on Linux.
This attitude is why many distro's sound support is godawful. Sometimes
I suspect they are testing on machines without speakers connected.
Lee
On 2/21/06, Lee Revell <[email protected]> wrote:
> On Mon, 2006-02-20 at 18:05 +0100, Olivier Galibert wrote:
> > Pavel, if you mean that the userspace code will not be reviewed to
> > standards the kernel code is, kill uswsusp _NOW_ before it does too
> > much damage. Unreliable suspend eats filesystems for breakfast. The
> > other userspace components of the kernels services are either optional
> > (udev) or not that important (alsa).
> >
>
> Why is sound less important than suspending, or networking, or any other
> subsystem? This is an insult to everyone who worked long and hard to
> get decent sound support on Linux.
>
I bet this was not meant as an insult. Quote: "Unreliable suspend eats
filesystems for breakfast". The worst thing mismatched ALSA library
could cause is noice in my speakers.
--
Dmitry
On Tue, 2006-02-21 at 17:17 -0500, Dmitry Torokhov wrote:
> On 2/21/06, Lee Revell <[email protected]> wrote:
> > On Mon, 2006-02-20 at 18:05 +0100, Olivier Galibert wrote:
> > > Pavel, if you mean that the userspace code will not be reviewed to
> > > standards the kernel code is, kill uswsusp _NOW_ before it does too
> > > much damage. Unreliable suspend eats filesystems for breakfast. The
> > > other userspace components of the kernels services are either optional
> > > (udev) or not that important (alsa).
> > >
> >
> > Why is sound less important than suspending, or networking, or any other
> > subsystem? This is an insult to everyone who worked long and hard to
> > get decent sound support on Linux.
> >
>
> I bet this was not meant as an insult. Quote: "Unreliable suspend eats
> filesystems for breakfast". The worst thing mismatched ALSA library
> could cause is noice in my speakers.
OK fair enough, I took that out of context.
Lee
Hi Rafael.
On Wednesday 22 February 2006 06:40, Rafael J. Wysocki wrote:
> On Tuesday 21 February 2006 05:19, Dmitry Torokhov wrote:
> > On Monday 20 February 2006 21:57, Nigel Cunningham wrote:
> > > For the record, my thinking went: swsusp uses n (12?) bytes of meta
> > > data for every page you save, where as using bitmaps makes that much
> > > closer to a constant value (a small variable amount for recording where
> > > the image will be stored in extents). 12 bytes per page is 3MB/1GB. If
> > > swsusp was to add support for multiple swap partitions or writing to
> > > files, those requirements might be closer to 5MB/GB.
> >
> > 5MB/GB amounts to 0.5% overhead, I don't think you should be concerned
> > here. Much more important IMHO is that IIRC swsusp requires to be able to
> > free 1/2 of the physical memory whuch is hard on low memory boxes.
>
> I see another point in using bitmaps: we could avoid modifying page flags
> and use bitmaps to store all of the temporary information. I thought about
> it for some time and I think it's doable.
It is doable - I'm doing it now, but am thinking about reverting part of the
code to use pbes again. If you're going to look at using bitmaps in place of
pbes, me changing would be a waste of time. Do you want me to hold off for a
while? (I'll happily do that, as I have far more than enough to keep me
occupied at the moment anyway).
Regards,
Nigel
Hi,
On Tuesday 21 February 2006 22:00, Nigel Cunningham wrote:
> On Wednesday 22 February 2006 06:40, Rafael J. Wysocki wrote:
> > On Tuesday 21 February 2006 05:19, Dmitry Torokhov wrote:
> > > On Monday 20 February 2006 21:57, Nigel Cunningham wrote:
> > > > For the record, my thinking went: swsusp uses n (12?) bytes of meta
> > > > data for every page you save, where as using bitmaps makes that much
> > > > closer to a constant value (a small variable amount for recording where
> > > > the image will be stored in extents). 12 bytes per page is 3MB/1GB. If
> > > > swsusp was to add support for multiple swap partitions or writing to
> > > > files, those requirements might be closer to 5MB/GB.
> > >
> > > 5MB/GB amounts to 0.5% overhead, I don't think you should be concerned
> > > here. Much more important IMHO is that IIRC swsusp requires to be able to
> > > free 1/2 of the physical memory whuch is hard on low memory boxes.
> >
> > I see another point in using bitmaps: we could avoid modifying page flags
> > and use bitmaps to store all of the temporary information. I thought about
> > it for some time and I think it's doable.
>
> It is doable - I'm doing it now, but am thinking about reverting part of the
> code to use pbes again. If you're going to look at using bitmaps in place of
> pbes, me changing would be a waste of time. Do you want me to hold off for a
> while? (I'll happily do that, as I have far more than enough to keep me
> occupied at the moment anyway).
Well, I'd say so. :-)
Frankly, I didn't think of dropping PBEs right now, but in the long run
that's worth considering, IMO. The advantage of PBEs is that they are easy to
handle in the assembly parts, but apart from this they are a bit wasteful
(not very much, though).
The fact that we use page flags to store some suspend/resume-related
information is a big disadvantage in my view, and I'd like to get rid of that
in the future. In principle we could use a bitmap, or rather two of them,
to store the same information independently of the page flags, and
if we use bitmaps for this purpose, we can use them also instead of
PBEs.
At this point I'd have to look at your snapshot-related code and see if
it's suitable for snapshot.c (in -mm now) somehow. If you could point
me to the specific parts of the suspend2 patch where this code is, I'd be
grateful.
Greetings,
Rafael
On Wednesday 22 February 2006 09:38, Rafael J. Wysocki wrote:
> On Tuesday 21 February 2006 22:00, Nigel Cunningham wrote:
> > On Wednesday 22 February 2006 06:40, Rafael J. Wysocki wrote:
> > > On Tuesday 21 February 2006 05:19, Dmitry Torokhov wrote:
> > > > On Monday 20 February 2006 21:57, Nigel Cunningham wrote:
> > > > > For the record, my thinking went: swsusp uses n (12?) bytes of meta
> > > > > data for every page you save, where as using bitmaps makes that
> > > > > much closer to a constant value (a small variable amount for
> > > > > recording where the image will be stored in extents). 12 bytes per
> > > > > page is 3MB/1GB. If swsusp was to add support for multiple swap
> > > > > partitions or writing to files, those requirements might be closer
> > > > > to 5MB/GB.
> > > >
> > > > 5MB/GB amounts to 0.5% overhead, I don't think you should be
> > > > concerned here. Much more important IMHO is that IIRC swsusp requires
> > > > to be able to free 1/2 of the physical memory whuch is hard on low
> > > > memory boxes.
> > >
> > > I see another point in using bitmaps: we could avoid modifying page
> > > flags and use bitmaps to store all of the temporary information. I
> > > thought about it for some time and I think it's doable.
> >
> > It is doable - I'm doing it now, but am thinking about reverting part of
> > the code to use pbes again. If you're going to look at using bitmaps in
> > place of pbes, me changing would be a waste of time. Do you want me to
> > hold off for a while? (I'll happily do that, as I have far more than
> > enough to keep me occupied at the moment anyway).
>
> Well, I'd say so. :-)
Ok.
> Frankly, I didn't think of dropping PBEs right now, but in the long run
> that's worth considering, IMO. The advantage of PBEs is that they are easy
> to handle in the assembly parts, but apart from this they are a bit
> wasteful (not very much, though).
Fully agree. That's why I've sought to keep the copying in c - it makes it
simpler to read and maintain (although at the expense of a little bit of
ugliness with that if in the stack page allocation or (old way) working hard
to make the C not use stack).
> The fact that we use page flags to store some suspend/resume-related
> information is a big disadvantage in my view, and I'd like to get rid of
> that in the future. In principle we could use a bitmap, or rather two of
> them, to store the same information independently of the page flags, and if
> we use bitmaps for this purpose, we can use them also instead of PBEs.
If you use the 'dynamically allocated pageflags' code (sure, pick a better
name if you want), these changes will be pretty trivial - you can #define
macros that could make the transition just a matter of switching PageNosave
(eg) to PageSomethingElse. (Ditto for setting and clearing flags).
> At this point I'd have to look at your snapshot-related code and see if
> it's suitable for snapshot.c (in -mm now) somehow. If you could point
> me to the specific parts of the suspend2 patch where this code is, I'd be
> grateful.
Sure. The bulk is in kernel/power/atomic_copy.c. Arch specific routines are
include/asm-<arch>/suspend2.h.
Regards,
Nigel
> Greetings,
> Rafael
Dmitry Torokhov wrote:
> On 2/21/06, Lee Revell <[email protected]> wrote:
>> On Mon, 2006-02-20 at 18:05 +0100, Olivier Galibert wrote:
>>> Pavel, if you mean that the userspace code will not be reviewed to
>>> standards the kernel code is, kill uswsusp _NOW_ before it does too
>>> much damage. Unreliable suspend eats filesystems for breakfast. The
>>> other userspace components of the kernels services are either optional
>>> (udev) or not that important (alsa).
>>>
>> Why is sound less important than suspending, or networking, or any other
>> subsystem? This is an insult to everyone who worked long and hard to
>> get decent sound support on Linux.
>>
>
> I bet this was not meant as an insult. Quote: "Unreliable suspend eats
> filesystems for breakfast". The worst thing mismatched ALSA library
> could cause is noice in my speakers.
If you've got a Linux powered stereo in your car, you're going like the
clappers and your speakers suddenly blast out white noise as loud as
they possibly can, you will wish you had enough seconds left to run a
measly fsck.
--
Tristan Wibberley
Matthias Hensler <[email protected]> writes:
> > > Third try sound was gone. On the fourth try the system hanged
> > > after starting ppracer (to test GLX/DRI on my i855).
> >
> > Submit AGP fixes, then.
>
> I think no such fixes are in Suspend 2, but still it works there.
actually there're (well i didn't compile nor test suspend2) in
100-suspend2-2.2-for-2.6.15.1.patch:
it introduces agp_suspend.h and uses it in the various agp backend
drivers in order to suspend/resume agp controllers (only for ati and
nvidia though).
On Wednesday 22 February 2006 00:47, Nigel Cunningham wrote:
> On Wednesday 22 February 2006 09:38, Rafael J. Wysocki wrote:
> > On Tuesday 21 February 2006 22:00, Nigel Cunningham wrote:
> > > On Wednesday 22 February 2006 06:40, Rafael J. Wysocki wrote:
> > > > On Tuesday 21 February 2006 05:19, Dmitry Torokhov wrote:
> > > > > On Monday 20 February 2006 21:57, Nigel Cunningham wrote:
> > > > > > For the record, my thinking went: swsusp uses n (12?) bytes of meta
> > > > > > data for every page you save, where as using bitmaps makes that
> > > > > > much closer to a constant value (a small variable amount for
> > > > > > recording where the image will be stored in extents). 12 bytes per
> > > > > > page is 3MB/1GB. If swsusp was to add support for multiple swap
> > > > > > partitions or writing to files, those requirements might be closer
> > > > > > to 5MB/GB.
> > > > >
> > > > > 5MB/GB amounts to 0.5% overhead, I don't think you should be
> > > > > concerned here. Much more important IMHO is that IIRC swsusp requires
> > > > > to be able to free 1/2 of the physical memory whuch is hard on low
> > > > > memory boxes.
> > > >
> > > > I see another point in using bitmaps: we could avoid modifying page
> > > > flags and use bitmaps to store all of the temporary information. I
> > > > thought about it for some time and I think it's doable.
> > >
> > > It is doable - I'm doing it now, but am thinking about reverting part of
> > > the code to use pbes again. If you're going to look at using bitmaps in
> > > place of pbes, me changing would be a waste of time. Do you want me to
> > > hold off for a while? (I'll happily do that, as I have far more than
> > > enough to keep me occupied at the moment anyway).
> >
> > Well, I'd say so. :-)
>
> Ok.
>
> > Frankly, I didn't think of dropping PBEs right now, but in the long run
> > that's worth considering, IMO. The advantage of PBEs is that they are easy
> > to handle in the assembly parts, but apart from this they are a bit
> > wasteful (not very much, though).
>
> Fully agree. That's why I've sought to keep the copying in c - it makes it
> simpler to read and maintain (although at the expense of a little bit of
> ugliness with that if in the stack page allocation
Well, that's a bit too much ugliness for me, sorry.
> or (old way) working hard to make the C not use stack).
I'd rather not get rid of the assembly parts. Instead, I'd modify them to
handle bitmaps. I'm not going to drop them.
> > The fact that we use page flags to store some suspend/resume-related
> > information is a big disadvantage in my view, and I'd like to get rid of
> > that in the future. In principle we could use a bitmap, or rather two of
> > them, to store the same information independently of the page flags, and if
> > we use bitmaps for this purpose, we can use them also instead of PBEs.
>
> If you use the 'dynamically allocated pageflags' code (sure, pick a better
> name if you want), these changes will be pretty trivial - you can #define
> macros that could make the transition just a matter of switching PageNosave
> (eg) to PageSomethingElse. (Ditto for setting and clearing flags).
I think it could be done without that code and I'd prefer to do so. In fact,
we only need to remember:
(a) saveable pages
(b) pages used to store the data from (a)
(c) pages allocated by us that we should release eventually
(generally that may be a broader set than just (b)).
That's 3 bitmaps total and no need for using any more sophisticated stuff,
if I remember everything correctly.
> > At this point I'd have to look at your snapshot-related code and see if
> > it's suitable for snapshot.c (in -mm now) somehow. If you could point
> > me to the specific parts of the suspend2 patch where this code is, I'd be
> > grateful.
>
> Sure. The bulk is in kernel/power/atomic_copy.c. Arch specific routines are
> include/asm-<arch>/suspend2.h.
OK, thanks.
Rafael
Hi!
> > It is doable - I'm doing it now, but am thinking about reverting part of the
> > code to use pbes again. If you're going to look at using bitmaps in place of
> > pbes, me changing would be a waste of time. Do you want me to hold off for a
> > while? (I'll happily do that, as I have far more than enough to keep me
> > occupied at the moment anyway).
>
> Well, I'd say so. :-)
>
> Frankly, I didn't think of dropping PBEs right now, but in the long run
> that's worth considering, IMO. The advantage of PBEs is that they are easy to
> handle in the assembly parts, but apart from this they are a bit wasteful
> (not very much, though).
Of course it will depend on what patch looks like, but changing
assembly parts is hard -- you have to change all the architectures,
and better not make any mistake.
> The fact that we use page flags to store some suspend/resume-related
> information is a big disadvantage in my view, and I'd like to get rid of that
> in the future. In principle we could use a bitmap, or rather two of them,
> to store the same information independently of the page flags, and
> if we use bitmaps for this purpose, we can use them also instead of
> PBEs.
Well, we "only" use 2 bits... :-).
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi.
On Thursday 23 February 2006 04:49, Rafael J. Wysocki wrote:
> > > Frankly, I didn't think of dropping PBEs right now, but in the long run
> > > that's worth considering, IMO. The advantage of PBEs is that they are
> > > easy to handle in the assembly parts, but apart from this they are a
> > > bit wasteful (not very much, though).
> >
> > Fully agree. That's why I've sought to keep the copying in c - it makes
> > it simpler to read and maintain (although at the expense of a little bit
> > of ugliness with that if in the stack page allocation
>
> Well, that's a bit too much ugliness for me, sorry.
>
> > or (old way) working hard to make the C not use stack).
>
> I'd rather not get rid of the assembly parts. Instead, I'd modify them to
> handle bitmaps. I'm not going to drop them.
Well, if you do this, and I can, I will start using the code too. I don't know
x86/x86_64/ppc/... assembly enough that I could help, but I would be willing
to drop the current code if yours was usable. Come to that, (as I already
said), I'm willing to work on switching to pbes prior to that and seeing if
we can share that code earlier, if you want me to and I can find the time.
> > > The fact that we use page flags to store some suspend/resume-related
> > > information is a big disadvantage in my view, and I'd like to get rid
> > > of that in the future. In principle we could use a bitmap, or rather
> > > two of them, to store the same information independently of the page
> > > flags, and if we use bitmaps for this purpose, we can use them also
> > > instead of PBEs.
> >
> > If you use the 'dynamically allocated pageflags' code (sure, pick a
> > better name if you want), these changes will be pretty trivial - you can
> > #define macros that could make the transition just a matter of switching
> > PageNosave (eg) to PageSomethingElse. (Ditto for setting and clearing
> > flags).
>
> I think it could be done without that code and I'd prefer to do so. In
> fact, we only need to remember:
> (a) saveable pages
> (b) pages used to store the data from (a)
> (c) pages allocated by us that we should release eventually
> (generally that may be a broader set than just (b)).
> That's 3 bitmaps total and no need for using any more sophisticated stuff,
> if I remember everything correctly.
Maybe I have tunnel vision, but I'd be surprised if you didn't end up with
something similar - I've tried to make it as simple as possible, and am
basically doing the same thing (even if I'm using different terms for some of
the concepts). I'd certainly be willing to interact on "Why did you do it
this way?" questions and make changes if a better way is shown to me.
> > > At this point I'd have to look at your snapshot-related code and see if
> > > it's suitable for snapshot.c (in -mm now) somehow. If you could point
> > > me to the specific parts of the suspend2 patch where this code is, I'd
> > > be grateful.
> >
> > Sure. The bulk is in kernel/power/atomic_copy.c. Arch specific routines
> > are include/asm-<arch>/suspend2.h.
>
> OK, thanks.
Thank you! I much prefer this kind of interaction. It's far more constructive.
Nigel
Hi,
On Wednesday 22 February 2006 23:41, Nigel Cunningham wrote:
> On Thursday 23 February 2006 04:49, Rafael J. Wysocki wrote:
> > > > Frankly, I didn't think of dropping PBEs right now, but in the long run
> > > > that's worth considering, IMO. The advantage of PBEs is that they are
> > > > easy to handle in the assembly parts, but apart from this they are a
> > > > bit wasteful (not very much, though).
> > >
> > > Fully agree. That's why I've sought to keep the copying in c - it makes
> > > it simpler to read and maintain (although at the expense of a little bit
> > > of ugliness with that if in the stack page allocation
> >
> > Well, that's a bit too much ugliness for me, sorry.
> >
> > > or (old way) working hard to make the C not use stack).
> >
> > I'd rather not get rid of the assembly parts. Instead, I'd modify them to
> > handle bitmaps. I'm not going to drop them.
>
> Well, if you do this, and I can, I will start using the code too. I don't know
> x86/x86_64/ppc/... assembly enough that I could help, but I would be willing
> to drop the current code if yours was usable. Come to that, (as I already
> said), I'm willing to work on switching to pbes prior to that and seeing if
> we can share that code earlier, if you want me to and I can find the time.
Yes, it would be nice if we could share some code earlier. However I think
the freezer is a better target short-term. If you could have a look at the
-mm freezer and tell us what you'd like to add to that, we'd probably be able
to get closer in that area.
> > > > The fact that we use page flags to store some suspend/resume-related
> > > > information is a big disadvantage in my view, and I'd like to get rid
> > > > of that in the future. In principle we could use a bitmap, or rather
> > > > two of them, to store the same information independently of the page
> > > > flags, and if we use bitmaps for this purpose, we can use them also
> > > > instead of PBEs.
> > >
> > > If you use the 'dynamically allocated pageflags' code (sure, pick a
> > > better name if you want), these changes will be pretty trivial - you can
> > > #define macros that could make the transition just a matter of switching
> > > PageNosave (eg) to PageSomethingElse. (Ditto for setting and clearing
> > > flags).
> >
> > I think it could be done without that code and I'd prefer to do so. In
> > fact, we only need to remember:
> > (a) saveable pages
> > (b) pages used to store the data from (a)
> > (c) pages allocated by us that we should release eventually
> > (generally that may be a broader set than just (b)).
> > That's 3 bitmaps total and no need for using any more sophisticated stuff,
> > if I remember everything correctly.
>
> Maybe I have tunnel vision, but I'd be surprised if you didn't end up with
> something similar - I've tried to make it as simple as possible, and am
> basically doing the same thing (even if I'm using different terms for some of
> the concepts). I'd certainly be willing to interact on "Why did you do it
> this way?" questions and make changes if a better way is shown to me.
OK
Greetings,
Rafael
Hi,
On Wednesday 22 February 2006 23:24, Pavel Machek wrote:
> > > It is doable - I'm doing it now, but am thinking about reverting part of the
> > > code to use pbes again. If you're going to look at using bitmaps in place of
> > > pbes, me changing would be a waste of time. Do you want me to hold off for a
> > > while? (I'll happily do that, as I have far more than enough to keep me
> > > occupied at the moment anyway).
> >
> > Well, I'd say so. :-)
> >
> > Frankly, I didn't think of dropping PBEs right now, but in the long run
> > that's worth considering, IMO. The advantage of PBEs is that they are easy to
> > handle in the assembly parts, but apart from this they are a bit wasteful
> > (not very much, though).
>
> Of course it will depend on what patch looks like, but changing
> assembly parts is hard -- you have to change all the architectures,
> and better not make any mistake.
Yes, that would be a lot of work, so it's rather a long term "vision".
I think we should try to get the pagecache stuff right first anyway.
> > The fact that we use page flags to store some suspend/resume-related
> > information is a big disadvantage in my view, and I'd like to get rid of that
> > in the future. In principle we could use a bitmap, or rather two of them,
> > to store the same information independently of the page flags, and
> > if we use bitmaps for this purpose, we can use them also instead of
> > PBEs.
>
> Well, we "only" use 2 bits... :-).
In my view the problem is this adds constraints that other people have to take
into account. Not a good thing if avoidable IMHO.
Greetings,
Rafael
Hi!
> > > > It is doable - I'm doing it now, but am thinking about reverting part of the
> > > > code to use pbes again. If you're going to look at using bitmaps in place of
> > > > pbes, me changing would be a waste of time. Do you want me to hold off for a
> > > > while? (I'll happily do that, as I have far more than enough to keep me
> > > > occupied at the moment anyway).
> > >
> > > Well, I'd say so. :-)
> > >
> > > Frankly, I didn't think of dropping PBEs right now, but in the long run
> > > that's worth considering, IMO. The advantage of PBEs is that they are easy to
> > > handle in the assembly parts, but apart from this they are a bit wasteful
> > > (not very much, though).
> >
> > Of course it will depend on what patch looks like, but changing
> > assembly parts is hard -- you have to change all the architectures,
> > and better not make any mistake.
>
> Yes, that would be a lot of work, so it's rather a long term
> "vision".
Ok, I have no problems with visions.
> I think we should try to get the pagecache stuff right first anyway.
Are you sure it is worth doing? I mean... it only helps on small
machines, no?
OTOH having it for benchmarks will be nice, and perhaps we could use
that kind it to speed up boot and similar things...
> > > The fact that we use page flags to store some suspend/resume-related
> > > information is a big disadvantage in my view, and I'd like to get rid of that
> > > in the future. In principle we could use a bitmap, or rather two of them,
> > > to store the same information independently of the page flags, and
> > > if we use bitmaps for this purpose, we can use them also instead of
> > > PBEs.
> >
> > Well, we "only" use 2 bits... :-).
>
> In my view the problem is this adds constraints that other people have to take
> into account. Not a good thing if avoidable IMHO.
Well, I hope that swsusp development will move to userland in future
:-).
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi.
On Thursday 23 February 2006 09:56, Pavel Machek wrote:
> > > > The fact that we use page flags to store some suspend/resume-related
> > > > information is a big disadvantage in my view, and I'd like to get rid
> > > > of that in the future. In principle we could use a bitmap, or rather
> > > > two of them, to store the same information independently of the page
> > > > flags, and if we use bitmaps for this purpose, we can use them also
> > > > instead of PBEs.
> > >
> > > Well, we "only" use 2 bits... :-).
> >
> > In my view the problem is this adds constraints that other people have to
> > take into account. Not a good thing if avoidable IMHO.
>
> Well, I hope that swsusp development will move to userland in future
>
> :-).
I don't get your point. I mean, we're talking about flags that record what
pages are going to be in the image, be atomically copied and so on. Are you
planning on trying to export the free page information and the like to
userspace too, along with atomic copy code?
Regards,
Nigel
Hi!
> > > > > The fact that we use page flags to store some suspend/resume-related
> > > > > information is a big disadvantage in my view, and I'd like to get rid
> > > > > of that in the future. In principle we could use a bitmap, or rather
> > > > > two of them, to store the same information independently of the page
> > > > > flags, and if we use bitmaps for this purpose, we can use them also
> > > > > instead of PBEs.
> > > >
> > > > Well, we "only" use 2 bits... :-).
> > >
> > > In my view the problem is this adds constraints that other people have to
> > > take into account. Not a good thing if avoidable IMHO.
> >
> > Well, I hope that swsusp development will move to userland in future
> >
> > :-).
>
> I don't get your point. I mean, we're talking about flags that record what
> pages are going to be in the image, be atomically copied and so on. Are you
> planning on trying to export the free page information and the like to
> userspace too, along with atomic copy code?
No, certainly not.
Rafael said something like "being limited is bad, because it makes it
hard to change in-kernel snapshoting code". My reply was something
like "I hope people will stop changing in-kernel swsusp code, and hack
userland instead".
Atomic copy code has to stay with kernel: it needs disabled
interrupts, access to all the RAM, etc. It screams "kernel code".
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi.
On Thursday 23 February 2006 10:33, Pavel Machek wrote:
> Hi!
>
> > > > > > The fact that we use page flags to store some
> > > > > > suspend/resume-related information is a big disadvantage in my
> > > > > > view, and I'd like to get rid of that in the future. In
> > > > > > principle we could use a bitmap, or rather two of them, to store
> > > > > > the same information independently of the page flags, and if we
> > > > > > use bitmaps for this purpose, we can use them also instead of
> > > > > > PBEs.
> > > > >
> > > > > Well, we "only" use 2 bits... :-).
> > > >
> > > > In my view the problem is this adds constraints that other people
> > > > have to take into account. Not a good thing if avoidable IMHO.
> > >
> > > Well, I hope that swsusp development will move to userland in future
> > >
> > > :-).
> >
> > I don't get your point. I mean, we're talking about flags that record
> > what pages are going to be in the image, be atomically copied and so on.
> > Are you planning on trying to export the free page information and the
> > like to userspace too, along with atomic copy code?
>
> No, certainly not.
>
> Rafael said something like "being limited is bad, because it makes it
> hard to change in-kernel snapshoting code". My reply was something
> like "I hope people will stop changing in-kernel swsusp code, and hack
> userland instead".
>
> Atomic copy code has to stay with kernel: it needs disabled
> interrupts, access to all the RAM, etc. It screams "kernel code".
Good to know. I was afraid you were losing the plot for a minute there :)
Nigel
Hi,
On Thursday 23 February 2006 00:56, Pavel Machek wrote:
> > > > > It is doable - I'm doing it now, but am thinking about reverting part of the
> > > > > code to use pbes again. If you're going to look at using bitmaps in place of
> > > > > pbes, me changing would be a waste of time. Do you want me to hold off for a
> > > > > while? (I'll happily do that, as I have far more than enough to keep me
> > > > > occupied at the moment anyway).
> > > >
> > > > Well, I'd say so. :-)
> > > >
> > > > Frankly, I didn't think of dropping PBEs right now, but in the long run
> > > > that's worth considering, IMO. The advantage of PBEs is that they are easy to
> > > > handle in the assembly parts, but apart from this they are a bit wasteful
> > > > (not very much, though).
> > >
> > > Of course it will depend on what patch looks like, but changing
> > > assembly parts is hard -- you have to change all the architectures,
> > > and better not make any mistake.
> >
> > Yes, that would be a lot of work, so it's rather a long term
> > "vision".
>
> Ok, I have no problems with visions.
>
> > I think we should try to get the pagecache stuff right first anyway.
>
> Are you sure it is worth doing? I mean... it only helps on small
> machines, no?
>
> OTOH having it for benchmarks will be nice, and perhaps we could use
> that kind it to speed up boot and similar things...
Currently some people can't suspend with the mainline code because it cannot
free as much memory as needed on their boxes. I think we should care for them
too.
Besides, if they could suspend, we'd have more users and more testing coverage
for device drivers, especially for devices that are no longer installed in
newer boxes. ;-)
Greetings,
Rafael
Hi,
On Thursday 23 February 2006 01:33, Pavel Machek wrote:
> > > > > > The fact that we use page flags to store some suspend/resume-related
> > > > > > information is a big disadvantage in my view, and I'd like to get rid
> > > > > > of that in the future. In principle we could use a bitmap, or rather
> > > > > > two of them, to store the same information independently of the page
> > > > > > flags, and if we use bitmaps for this purpose, we can use them also
> > > > > > instead of PBEs.
> > > > >
> > > > > Well, we "only" use 2 bits... :-).
> > > >
> > > > In my view the problem is this adds constraints that other people have to
> > > > take into account. Not a good thing if avoidable IMHO.
> > >
> > > Well, I hope that swsusp development will move to userland in future
> > >
> > > :-).
> >
> > I don't get your point. I mean, we're talking about flags that record what
> > pages are going to be in the image, be atomically copied and so on. Are you
> > planning on trying to export the free page information and the like to
> > userspace too, along with atomic copy code?
>
> No, certainly not.
>
> Rafael said something like "being limited is bad, because it makes it
> hard to change in-kernel snapshoting code". My reply was something
> like "I hope people will stop changing in-kernel swsusp code, and hack
> userland instead".
Actually I meant all of the other users of page flags. If we didn't use page
flags, they would be less constrained in what they're doing.
Greetings,
Rafael
Hi!
> > Ok, I have no problems with visions.
> >
> > > I think we should try to get the pagecache stuff right first anyway.
> >
> > Are you sure it is worth doing? I mean... it only helps on small
> > machines, no?
> >
> > OTOH having it for benchmarks will be nice, and perhaps we could use
> > that kind it to speed up boot and similar things...
>
> Currently some people can't suspend with the mainline code because it cannot
> free as much memory as needed on their boxes. I think we should care for them
> too.
But saving pagecache will not help them *at all*!
[Because pagecache is freeable, anyway, so it will be freed. Now... I
have seen some problems where free_some_memory did not free enough,
and schedule()/retry helped a bit... that probably should be fixed.]
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Wed, Feb 22, 2006 at 05:15:26PM +0100, Thierry Vignaud wrote:
> Matthias Hensler <[email protected]> writes:
>
> > > > Third try sound was gone. On the fourth try the system hanged
> > > > after starting ppracer (to test GLX/DRI on my i855).
> > >
> > > Submit AGP fixes, then.
> >
> > I think no such fixes are in Suspend 2, but still it works there.
>
> actually there're (well i didn't compile nor test suspend2) in
> 100-suspend2-2.2-for-2.6.15.1.patch:
>
> it introduces agp_suspend.h and uses it in the various agp backend
> drivers in order to suspend/resume agp controllers (only for ati and
> nvidia though).
if they're the patches I'm thinking of, equivalent fixes went into 2.6.16rc already
Dave
Hi,
On Thursday 23 February 2006 13:17, Pavel Machek wrote:
> > > Ok, I have no problems with visions.
> > >
> > > > I think we should try to get the pagecache stuff right first anyway.
> > >
> > > Are you sure it is worth doing? I mean... it only helps on small
> > > machines, no?
> > >
> > > OTOH having it for benchmarks will be nice, and perhaps we could use
> > > that kind it to speed up boot and similar things...
> >
> > Currently some people can't suspend with the mainline code because it cannot
> > free as much memory as needed on their boxes. I think we should care for them
> > too.
>
> But saving pagecache will not help them *at all*!
>
> [Because pagecache is freeable, anyway, so it will be freed. Now... I
> have seen some problems where free_some_memory did not free enough,
> and schedule()/retry helped a bit... that probably should be fixed.]
It seems I need to understand correctly what the difference between what
we do and what Nigel does is. I thought the Nigel's approach was to save
some cache pages to disk first and use the memory occupied by them to
store the image data. If so, is the page cache involved in that or something
else?
Rafael
On Čt 23-02-06 23:37:30, Rafael J. Wysocki wrote:
> Hi,
>
> On Thursday 23 February 2006 13:17, Pavel Machek wrote:
> > > > Ok, I have no problems with visions.
> > > >
> > > > > I think we should try to get the pagecache stuff right first anyway.
> > > >
> > > > Are you sure it is worth doing? I mean... it only helps on small
> > > > machines, no?
> > > >
> > > > OTOH having it for benchmarks will be nice, and perhaps we could use
> > > > that kind it to speed up boot and similar things...
> > >
> > > Currently some people can't suspend with the mainline code because it cannot
> > > free as much memory as needed on their boxes. I think we should care for them
> > > too.
> >
> > But saving pagecache will not help them *at all*!
> >
> > [Because pagecache is freeable, anyway, so it will be freed. Now... I
> > have seen some problems where free_some_memory did not free enough,
> > and schedule()/retry helped a bit... that probably should be fixed.]
>
> It seems I need to understand correctly what the difference between what
> we do and what Nigel does is. I thought the Nigel's approach was to save
> some cache pages to disk first and use the memory occupied by them to
> store the image data. If so, is the page cache involved in that or something
> else?
I believe Nigel only saves pages that could have been freed anyway
during phase1. Nigel, correct me here... suspend2 should work on same
class of machines swsusp can, but will be able to save caches on
machines where swsusp can not save any.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Friday 24 February 2006 08:37, Rafael J. Wysocki wrote:
> Hi,
>
> On Thursday 23 February 2006 13:17, Pavel Machek wrote:
> > > > Ok, I have no problems with visions.
> > > >
> > > > > I think we should try to get the pagecache stuff right first
> > > > > anyway.
> > > >
> > > > Are you sure it is worth doing? I mean... it only helps on small
> > > > machines, no?
> > > >
> > > > OTOH having it for benchmarks will be nice, and perhaps we could use
> > > > that kind it to speed up boot and similar things...
> > >
> > > Currently some people can't suspend with the mainline code because it
> > > cannot free as much memory as needed on their boxes. I think we should
> > > care for them too.
> >
> > But saving pagecache will not help them *at all*!
> >
> > [Because pagecache is freeable, anyway, so it will be freed. Now... I
> > have seen some problems where free_some_memory did not free enough,
> > and schedule()/retry helped a bit... that probably should be fixed.]
>
> It seems I need to understand correctly what the difference between what
> we do and what Nigel does is. I thought the Nigel's approach was to save
> some cache pages to disk first and use the memory occupied by them to
> store the image data. If so, is the page cache involved in that or
> something else?
You're right. The only point I would query is that I'm not sure on terminology
- whether 'page cache' == LRU. In case there's any difference, I'll say that
I treat pages on the active and inactive LRU lists separately, saving them to
disk first and using the memory occupied by them for the atomic copy (with
the exception, of course, of pages belonging to processes such as userui -
these are made part of the atomic copy and not overwritten).
Regards,
Nigel
Hi.
On Friday 24 February 2006 09:04, Pavel Machek wrote:
> > > [Because pagecache is freeable, anyway, so it will be freed. Now... I
> > > have seen some problems where free_some_memory did not free enough,
> > > and schedule()/retry helped a bit... that probably should be fixed.]
> >
> > It seems I need to understand correctly what the difference between what
> > we do and what Nigel does is. I thought the Nigel's approach was to save
> > some cache pages to disk first and use the memory occupied by them to
> > store the image data. If so, is the page cache involved in that or
> > something else?
>
> I believe Nigel only saves pages that could have been freed anyway
> during phase1. Nigel, correct me here... suspend2 should work on same
> class of machines swsusp can, but will be able to save caches on
> machines where swsusp can not save any.
I'm not used to thinking in these terms :). It would be normally be right,
except that there will be some LRU pages that will never be freed. These
would allow suspend2 to work in some (not many) cases where swsusp can't.
It's been ages since I did the intensive testing on the image preparation
code, but I think that if we free as much memory as we can, we will always
still have at least a few hundred LRU pages left. That's not much, but on
machines with less ram, it might make the difference in a greater percentage
of cases (compared to machines with more ram)?
If there were other pages that could be safely included in this set, we could
perhaps make more cases where suspend2 could work but swsusp couldn't. LRU
was low hanging fruit, and I didn't bother looking beyond it.
Nigel
Hi!
> > > > [Because pagecache is freeable, anyway, so it will be freed. Now... I
> > > > have seen some problems where free_some_memory did not free enough,
> > > > and schedule()/retry helped a bit... that probably should be fixed.]
> > >
> > > It seems I need to understand correctly what the difference between what
> > > we do and what Nigel does is. I thought the Nigel's approach was to save
> > > some cache pages to disk first and use the memory occupied by them to
> > > store the image data. If so, is the page cache involved in that or
> > > something else?
> >
> > I believe Nigel only saves pages that could have been freed anyway
> > during phase1. Nigel, correct me here... suspend2 should work on same
> > class of machines swsusp can, but will be able to save caches on
> > machines where swsusp can not save any.
>
> I'm not used to thinking in these terms :). It would be normally be right,
> except that there will be some LRU pages that will never be freed. These
> would allow suspend2 to work in some (not many) cases where swsusp can't.
> It's been ages since I did the intensive testing on the image preparation
> code, but I think that if we free as much memory as we can, we will always
> still have at least a few hundred LRU pages left. That's not much, but on
> machines with less ram, it might make the difference in a greater percentage
> of cases (compared to machines with more ram)?
Well, pages in LRU should be user pages, and therefore freeable,
AFAICT. It is possible that there's something wrong with freeing in
swsusp1...
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi,
On Friday 24 February 2006 00:44, Pavel Machek wrote:
> > > > > [Because pagecache is freeable, anyway, so it will be freed. Now... I
> > > > > have seen some problems where free_some_memory did not free enough,
> > > > > and schedule()/retry helped a bit... that probably should be fixed.]
> > > >
> > > > It seems I need to understand correctly what the difference between what
> > > > we do and what Nigel does is. I thought the Nigel's approach was to save
> > > > some cache pages to disk first and use the memory occupied by them to
> > > > store the image data. If so, is the page cache involved in that or
> > > > something else?
> > >
> > > I believe Nigel only saves pages that could have been freed anyway
> > > during phase1. Nigel, correct me here... suspend2 should work on same
> > > class of machines swsusp can, but will be able to save caches on
> > > machines where swsusp can not save any.
> >
> > I'm not used to thinking in these terms :). It would be normally be right,
> > except that there will be some LRU pages that will never be freed. These
> > would allow suspend2 to work in some (not many) cases where swsusp can't.
> > It's been ages since I did the intensive testing on the image preparation
> > code, but I think that if we free as much memory as we can, we will always
> > still have at least a few hundred LRU pages left. That's not much, but on
> > machines with less ram, it might make the difference in a greater percentage
> > of cases (compared to machines with more ram)?
>
> Well, pages in LRU should be user pages, and therefore freeable,
> AFAICT. It is possible that there's something wrong with freeing in
> swsusp1...
Well, if all of the pages that Nigel saves before snapshot are freeable in
theory, there evidently is something wrong with freeing in swsusp, as we
have a testcase in which the user was unable to suspend with swsusp due
to the lack of memory and could suspend with suspend2.
However, the only thing in swsusp_shrink_memory() that may be wrong
is we return -ENOMEM as soon as shrink_all_memory() returns 0.
Namely, if shrink_all_memory() can return 0 prematurely (ie. "there still are
some freeable pages, but they could not be freed in _this_ call"), we should
continue until it returns 0 twice in a row (or something like that). If this
doesn't help, we'll have to fix shrink_all_memory() I'm afraid.
Greetings,
Rafael
On P? 24-02-06 11:58:07, Rafael J. Wysocki wrote:
> Hi,
>
> On Friday 24 February 2006 00:44, Pavel Machek wrote:
> > > > > > [Because pagecache is freeable, anyway, so it will be freed. Now... I
> > > > > > have seen some problems where free_some_memory did not free enough,
> > > > > > and schedule()/retry helped a bit... that probably should be fixed.]
> > > > >
> > > > > It seems I need to understand correctly what the difference between what
> > > > > we do and what Nigel does is. I thought the Nigel's approach was to save
> > > > > some cache pages to disk first and use the memory occupied by them to
> > > > > store the image data. If so, is the page cache involved in that or
> > > > > something else?
> > > >
> > > > I believe Nigel only saves pages that could have been freed anyway
> > > > during phase1. Nigel, correct me here... suspend2 should work on same
> > > > class of machines swsusp can, but will be able to save caches on
> > > > machines where swsusp can not save any.
> > >
> > > I'm not used to thinking in these terms :). It would be normally be right,
> > > except that there will be some LRU pages that will never be freed. These
> > > would allow suspend2 to work in some (not many) cases where swsusp can't.
> > > It's been ages since I did the intensive testing on the image preparation
> > > code, but I think that if we free as much memory as we can, we will always
> > > still have at least a few hundred LRU pages left. That's not much, but on
> > > machines with less ram, it might make the difference in a greater percentage
> > > of cases (compared to machines with more ram)?
> >
> > Well, pages in LRU should be user pages, and therefore freeable,
> > AFAICT. It is possible that there's something wrong with freeing in
> > swsusp1...
>
> Well, if all of the pages that Nigel saves before snapshot are freeable in
> theory, there evidently is something wrong with freeing in swsusp, as we
> have a testcase in which the user was unable to suspend with swsusp due
> to the lack of memory and could suspend with suspend2.
>
> However, the only thing in swsusp_shrink_memory() that may be wrong
> is we return -ENOMEM as soon as shrink_all_memory() returns 0.
> Namely, if shrink_all_memory() can return 0 prematurely (ie. "there still are
> some freeable pages, but they could not be freed in _this_ call"), we should
> continue until it returns 0 twice in a row (or something like that). If this
> doesn't help, we'll have to fix shrink_all_memory() I'm afraid.
I did try shrink_all_memory() five times, with .5 second delay between
them, and it freed more memory at later tries. Sometimes it even freed
0 pages at the first try.
I did not push the patch because
1) it was way too ugly
2) shrink_all_memory() should be fixed. It should not really return if
there are more pages freeable.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi,
On Friday 24 February 2006 14:12, Pavel Machek wrote:
> On P? 24-02-06 11:58:07, Rafael J. Wysocki wrote:
> > On Friday 24 February 2006 00:44, Pavel Machek wrote:
> > > > > > > [Because pagecache is freeable, anyway, so it will be freed. Now... I
> > > > > > > have seen some problems where free_some_memory did not free enough,
> > > > > > > and schedule()/retry helped a bit... that probably should be fixed.]
> > > > > >
> > > > > > It seems I need to understand correctly what the difference between what
> > > > > > we do and what Nigel does is. I thought the Nigel's approach was to save
> > > > > > some cache pages to disk first and use the memory occupied by them to
> > > > > > store the image data. If so, is the page cache involved in that or
> > > > > > something else?
> > > > >
> > > > > I believe Nigel only saves pages that could have been freed anyway
> > > > > during phase1. Nigel, correct me here... suspend2 should work on same
> > > > > class of machines swsusp can, but will be able to save caches on
> > > > > machines where swsusp can not save any.
> > > >
> > > > I'm not used to thinking in these terms :). It would be normally be right,
> > > > except that there will be some LRU pages that will never be freed. These
> > > > would allow suspend2 to work in some (not many) cases where swsusp can't.
> > > > It's been ages since I did the intensive testing on the image preparation
> > > > code, but I think that if we free as much memory as we can, we will always
> > > > still have at least a few hundred LRU pages left. That's not much, but on
> > > > machines with less ram, it might make the difference in a greater percentage
> > > > of cases (compared to machines with more ram)?
> > >
> > > Well, pages in LRU should be user pages, and therefore freeable,
> > > AFAICT. It is possible that there's something wrong with freeing in
> > > swsusp1...
> >
> > Well, if all of the pages that Nigel saves before snapshot are freeable in
> > theory, there evidently is something wrong with freeing in swsusp, as we
> > have a testcase in which the user was unable to suspend with swsusp due
> > to the lack of memory and could suspend with suspend2.
> >
> > However, the only thing in swsusp_shrink_memory() that may be wrong
> > is we return -ENOMEM as soon as shrink_all_memory() returns 0.
> > Namely, if shrink_all_memory() can return 0 prematurely (ie. "there still are
> > some freeable pages, but they could not be freed in _this_ call"), we should
> > continue until it returns 0 twice in a row (or something like that). If this
> > doesn't help, we'll have to fix shrink_all_memory() I'm afraid.
>
> I did try shrink_all_memory() five times, with .5 second delay between
> them, and it freed more memory at later tries.
I wonder if the delays are essential or if so, whether they may be shorter
than .5 sec.
> Sometimes it even freed 0 pages at the first try.
>
> I did not push the patch because
>
> 1) it was way too ugly
I think I can do something like that in swsusp_shrink_memory() and it
won't be very ugly.
> 2) shrink_all_memory() should be fixed. It should not really return if
> there are more pages freeable.
Well, that would be a long-run solution. However, until it's fixed we can
use a workaround IMHO. ;-)
Greetings,
Rafael
Hi.
On Saturday 25 February 2006 06:22, Rafael J. Wysocki wrote:
> On Friday 24 February 2006 14:12, Pavel Machek wrote:
> > On P? 24-02-06 11:58:07, Rafael J. Wysocki wrote:
> > > On Friday 24 February 2006 00:44, Pavel Machek wrote:
> > > > > > > > [Because pagecache is freeable, anyway, so it will be freed.
> > > > > > > > Now... I have seen some problems where free_some_memory did
> > > > > > > > not free enough, and schedule()/retry helped a bit... that
> > > > > > > > probably should be fixed.]
> > > > > > >
> > > > > > > It seems I need to understand correctly what the difference
> > > > > > > between what we do and what Nigel does is. I thought the
> > > > > > > Nigel's approach was to save some cache pages to disk first and
> > > > > > > use the memory occupied by them to store the image data. If
> > > > > > > so, is the page cache involved in that or something else?
> > > > > >
> > > > > > I believe Nigel only saves pages that could have been freed
> > > > > > anyway during phase1. Nigel, correct me here... suspend2 should
> > > > > > work on same class of machines swsusp can, but will be able to
> > > > > > save caches on machines where swsusp can not save any.
> > > > >
> > > > > I'm not used to thinking in these terms :). It would be normally be
> > > > > right, except that there will be some LRU pages that will never be
> > > > > freed. These would allow suspend2 to work in some (not many) cases
> > > > > where swsusp can't. It's been ages since I did the intensive
> > > > > testing on the image preparation code, but I think that if we free
> > > > > as much memory as we can, we will always still have at least a few
> > > > > hundred LRU pages left. That's not much, but on machines with less
> > > > > ram, it might make the difference in a greater percentage of cases
> > > > > (compared to machines with more ram)?
> > > >
> > > > Well, pages in LRU should be user pages, and therefore freeable,
> > > > AFAICT. It is possible that there's something wrong with freeing in
> > > > swsusp1...
> > >
> > > Well, if all of the pages that Nigel saves before snapshot are freeable
> > > in theory, there evidently is something wrong with freeing in swsusp,
> > > as we have a testcase in which the user was unable to suspend with
> > > swsusp due to the lack of memory and could suspend with suspend2.
> > >
> > > However, the only thing in swsusp_shrink_memory() that may be wrong
> > > is we return -ENOMEM as soon as shrink_all_memory() returns 0.
> > > Namely, if shrink_all_memory() can return 0 prematurely (ie. "there
> > > still are some freeable pages, but they could not be freed in _this_
> > > call"), we should continue until it returns 0 twice in a row (or
> > > something like that). If this doesn't help, we'll have to fix
> > > shrink_all_memory() I'm afraid.
> >
> > I did try shrink_all_memory() five times, with .5 second delay between
> > them, and it freed more memory at later tries.
>
> I wonder if the delays are essential or if so, whether they may be shorter
> than .5 sec.
>
> > Sometimes it even freed 0 pages at the first try.
> >
> > I did not push the patch because
> >
> > 1) it was way too ugly
>
> I think I can do something like that in swsusp_shrink_memory() and it
> won't be very ugly.
>
> > 2) shrink_all_memory() should be fixed. It should not really return if
> > there are more pages freeable.
>
> Well, that would be a long-run solution. However, until it's fixed we can
> use a workaround IMHO. ;-)
Isn't trying to free as much memory as you can the wrong solution anyway? I
mean, that only means that the poor system has more pages to fault back in at
resume time, before the user can even begin to think about doing anything
useful. You might be able to say "Every machine that suspend2 works on,
swsusp works on", but the later will be a pretty sad definition of works!
Regards,
Nigel
Hi!
> > > 2) shrink_all_memory() should be fixed. It should not really return if
> > > there are more pages freeable.
> >
> > Well, that would be a long-run solution. However, until it's fixed we can
> > use a workaround IMHO. ;-)
>
> Isn't trying to free as much memory as you can the wrong solution anyway? I
> mean, that only means that the poor system has more pages to fault back in at
> resume time, before the user can even begin to think about doing anything
> useful. You might be able to say "Every machine that suspend2 works on,
> swsusp works on", but the later will be a pretty sad definition of works!
We are trying to catch a bug here. suspend2 or not, it is a bug and it
should be fixed (or at least understood).
[Also please try to tone down your messages. Your suspend2 may be more
user-friendly, you do not want to start that flamewar again, do you?
Saying "don't bother fixing that" is not nice thing to do.]
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi!
> > I did try shrink_all_memory() five times, with .5 second delay between
> > them, and it freed more memory at later tries.
>
> I wonder if the delays are essential or if so, whether they may be shorter
> than .5 sec.
I was using this with some success... (Warning, against old
kernel). But, as I said, I consider it ugly, and it would be better to
fix shrink_all_memory.
Pavel
diff --git a/kernel/power/disk.c b/kernel/power/disk.c
--- a/kernel/power/disk.c
+++ b/kernel/power/disk.c
@@ -84,20 +84,26 @@ static int in_suspend __nosavedata = 0;
static void free_some_memory(void)
{
- unsigned int i = 0;
- unsigned int tmp;
- unsigned long pages = 0;
- char *p = "-\\|/";
-
- printk("Freeing memory... ");
- while ((tmp = shrink_all_memory(10000))) {
- pages += tmp;
- printk("\b%c", p[i++ % 4]);
+ int i;
+ for (i=0; i<5; i++) {
+ int i = 0, tmp;
+ long pages = 0;
+ char *p = "-\\|/";
+
+ printk("Freeing memory... ");
+ while ((tmp = shrink_all_memory(10000))) {
+ pages += tmp;
+ printk("\b%c", p[i]);
+ i++;
+ if (i > 3)
+ i = 0;
+ }
+ printk("\bdone (%li pages freed)\n", pages);
+ msleep_interruptible(200);
}
- printk("\bdone (%li pages freed)\n", pages);
}
-
+/* FIXME: Call it when appropriate */
static inline void platform_finish(void)
{
if (pm_disk_mode == PM_DISK_PLATFORM) {
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On So 25-02-06 00:53:21, Pavel Machek wrote:
> Hi!
>
> > > > 2) shrink_all_memory() should be fixed. It should not really return if
> > > > there are more pages freeable.
> > >
> > > Well, that would be a long-run solution. However, until it's fixed we can
> > > use a workaround IMHO. ;-)
> >
> > Isn't trying to free as much memory as you can the wrong solution anyway? I
> > mean, that only means that the poor system has more pages to fault back in at
> > resume time, before the user can even begin to think about doing anything
> > useful. You might be able to say "Every machine that suspend2 works on,
> > swsusp works on", but the later will be a pretty sad definition of works!
>
> We are trying to catch a bug here. suspend2 or not, it is a bug and it
> should be fixed (or at least understood).
>
> [Also please try to tone down your messages. Your suspend2 may be more
> user-friendly, you do not want to start that flamewar again, do you?
> Saying "don't bother fixing that" is not nice thing to do.]
Heh, I guess I should apologize for being offtopic on suspend2 mailing
list... this was not about suspend2 any more..
I guess we should drop suspend2 and this huge cc list from future
discussion. (And fix subject.)
Anyway, Rafael, do you think you could commit your encryption patches?
Ready or not, bugs can be fixed later :-). [I'd like to do some work
based on them; I think I figured out easy way to setup suspend so that
password is needed only during resume...]
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi,
On Saturday 25 February 2006 00:11, Nigel Cunningham wrote:
> On Saturday 25 February 2006 06:22, Rafael J. Wysocki wrote:
> > On Friday 24 February 2006 14:12, Pavel Machek wrote:
> > > On Pá 24-02-06 11:58:07, Rafael J. Wysocki wrote:
}-- snip --{
> > > > Well, if all of the pages that Nigel saves before snapshot are freeable
> > > > in theory, there evidently is something wrong with freeing in swsusp,
> > > > as we have a testcase in which the user was unable to suspend with
> > > > swsusp due to the lack of memory and could suspend with suspend2.
> > > >
> > > > However, the only thing in swsusp_shrink_memory() that may be wrong
> > > > is we return -ENOMEM as soon as shrink_all_memory() returns 0.
> > > > Namely, if shrink_all_memory() can return 0 prematurely (ie. "there
> > > > still are some freeable pages, but they could not be freed in _this_
> > > > call"), we should continue until it returns 0 twice in a row (or
> > > > something like that). If this doesn't help, we'll have to fix
> > > > shrink_all_memory() I'm afraid.
> > >
> > > I did try shrink_all_memory() five times, with .5 second delay between
> > > them, and it freed more memory at later tries.
> >
> > I wonder if the delays are essential or if so, whether they may be shorter
> > than .5 sec.
> >
> > > Sometimes it even freed 0 pages at the first try.
> > >
> > > I did not push the patch because
> > >
> > > 1) it was way too ugly
> >
> > I think I can do something like that in swsusp_shrink_memory() and it
> > won't be very ugly.
> >
> > > 2) shrink_all_memory() should be fixed. It should not really return if
> > > there are more pages freeable.
> >
> > Well, that would be a long-run solution. However, until it's fixed we can
> > use a workaround IMHO. ;-)
>
> Isn't trying to free as much memory as you can the wrong solution anyway?
No, it isn't. There are situations in which we would like to suspend "whatever
it takes" and then we should be able to free as much memory as _really_
possible.
Besides, it is supposed to work, and it doesn't, so it needs fixing.
> I mean, that only means that the poor system has more pages to fault back in at
> resume time, before the user can even begin to think about doing anything
> useful.
Well, that's not the only possibility. After we fix the memory freeing issue
we can use the observation that page cache pages need not be saved
to disk during suspend, because they already are in a storage. We only
need to create a map of these pages during suspend with the information
on where to get them from and prefetch them into memory during resume
independently of the page fault mechanism.
This way we won't have to actually save anything before we snapshot the
system and the system should be reasonably responsive after resume.
Greetings,
Rafael
Hi.
On Saturday 25 February 2006 09:53, Pavel Machek wrote:
> Hi!
>
> > > > 2) shrink_all_memory() should be fixed. It should not really return
> > > > if there are more pages freeable.
> > >
> > > Well, that would be a long-run solution. However, until it's fixed we
> > > can use a workaround IMHO. ;-)
> >
> > Isn't trying to free as much memory as you can the wrong solution anyway?
> > I mean, that only means that the poor system has more pages to fault back
> > in at resume time, before the user can even begin to think about doing
> > anything useful. You might be able to say "Every machine that suspend2
> > works on, swsusp works on", but the later will be a pretty sad definition
> > of works!
>
> We are trying to catch a bug here. suspend2 or not, it is a bug and it
> should be fixed (or at least understood).
>
> [Also please try to tone down your messages. Your suspend2 may be more
> user-friendly, you do not want to start that flamewar again, do you?
> Saying "don't bother fixing that" is not nice thing to do.]
What's the bug?
Regards,
Nigel
Hi.
On Saturday 25 February 2006 10:20, Rafael J. Wysocki wrote:
> Hi,
>
> On Saturday 25 February 2006 00:11, Nigel Cunningham wrote:
> > On Saturday 25 February 2006 06:22, Rafael J. Wysocki wrote:
> > > On Friday 24 February 2006 14:12, Pavel Machek wrote:
> > > > On Pá 24-02-06 11:58:07, Rafael J. Wysocki wrote:
>
> }-- snip --{
>
> > > > > Well, if all of the pages that Nigel saves before snapshot are
> > > > > freeable in theory, there evidently is something wrong with freeing
> > > > > in swsusp, as we have a testcase in which the user was unable to
> > > > > suspend with swsusp due to the lack of memory and could suspend
> > > > > with suspend2.
> > > > >
> > > > > However, the only thing in swsusp_shrink_memory() that may be wrong
> > > > > is we return -ENOMEM as soon as shrink_all_memory() returns 0.
> > > > > Namely, if shrink_all_memory() can return 0 prematurely (ie. "there
> > > > > still are some freeable pages, but they could not be freed in
> > > > > _this_ call"), we should continue until it returns 0 twice in a row
> > > > > (or something like that). If this doesn't help, we'll have to fix
> > > > > shrink_all_memory() I'm afraid.
> > > >
> > > > I did try shrink_all_memory() five times, with .5 second delay
> > > > between them, and it freed more memory at later tries.
> > >
> > > I wonder if the delays are essential or if so, whether they may be
> > > shorter than .5 sec.
> > >
> > > > Sometimes it even freed 0 pages at the first try.
> > > >
> > > > I did not push the patch because
> > > >
> > > > 1) it was way too ugly
> > >
> > > I think I can do something like that in swsusp_shrink_memory() and it
> > > won't be very ugly.
> > >
> > > > 2) shrink_all_memory() should be fixed. It should not really return
> > > > if there are more pages freeable.
> > >
> > > Well, that would be a long-run solution. However, until it's fixed we
> > > can use a workaround IMHO. ;-)
> >
> > Isn't trying to free as much memory as you can the wrong solution anyway?
>
> No, it isn't. There are situations in which we would like to suspend
> "whatever it takes" and then we should be able to free as much memory as
> _really_ possible.
>
> Besides, it is supposed to work, and it doesn't, so it needs fixing.
>
> > I mean, that only means that the poor system has more pages to fault back
> > in at resume time, before the user can even begin to think about doing
> > anything useful.
>
> Well, that's not the only possibility. After we fix the memory freeing
> issue we can use the observation that page cache pages need not be saved to
> disk during suspend, because they already are in a storage. We only need
> to create a map of these pages during suspend with the information on where
> to get them from and prefetch them into memory during resume independently
> of the page fault mechanism.
>
> This way we won't have to actually save anything before we snapshot the
> system and the system should be reasonably responsive after resume.
But this is going to be much more complicated than simply saving the pages in
the first place. You'll need some mechanism for figuring out what pages to
get, how to fault them in, etc. In addition, it will be much slower than
simply reading them back from (ideally) contiguous storage.
Regards,
Nigel
Hi!
> > We are trying to catch a bug here. suspend2 or not, it is a bug and it
> > should be fixed (or at least understood).
> >
> > [Also please try to tone down your messages. Your suspend2 may be more
> > user-friendly, you do not want to start that flamewar again, do you?
> > Saying "don't bother fixing that" is not nice thing to do.]
>
> What's the bug?
shrink_all_memory() returns zero, even throught there are still pages
freeable.
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi,
On Saturday 25 February 2006 01:15, Pavel Machek wrote:
> On So 25-02-06 00:53:21, Pavel Machek wrote:
> > > > > 2) shrink_all_memory() should be fixed. It should not really return if
> > > > > there are more pages freeable.
> > > >
> > > > Well, that would be a long-run solution. However, until it's fixed we can
> > > > use a workaround IMHO. ;-)
> > >
> > > Isn't trying to free as much memory as you can the wrong solution anyway? I
> > > mean, that only means that the poor system has more pages to fault back in at
> > > resume time, before the user can even begin to think about doing anything
> > > useful. You might be able to say "Every machine that suspend2 works on,
> > > swsusp works on", but the later will be a pretty sad definition of works!
> >
> > We are trying to catch a bug here. suspend2 or not, it is a bug and it
> > should be fixed (or at least understood).
> >
> > [Also please try to tone down your messages. Your suspend2 may be more
> > user-friendly, you do not want to start that flamewar again, do you?
> > Saying "don't bother fixing that" is not nice thing to do.]
>
> Heh, I guess I should apologize for being offtopic on suspend2 mailing
> list... this was not about suspend2 any more..
>
> I guess we should drop suspend2 and this huge cc list from future
> discussion. (And fix subject.)
>
> Anyway, Rafael, do you think you could commit your encryption patches?
> Ready or not, bugs can be fixed later :-). [I'd like to do some work
> based on them; I think I figured out easy way to setup suspend so that
> password is needed only during resume...]
Done. I've also committed the patch to arrange the error messages in suspend
in a better way.
Greetings,
Rafael
On So 25-02-06 10:26:17, Nigel Cunningham wrote:
> Hi.
>
> On Saturday 25 February 2006 10:20, Rafael J. Wysocki wrote:
> > Hi,
> >
> > On Saturday 25 February 2006 00:11, Nigel Cunningham wrote:
> > > On Saturday 25 February 2006 06:22, Rafael J. Wysocki wrote:
> > > > On Friday 24 February 2006 14:12, Pavel Machek wrote:
> > > > > On P? 24-02-06 11:58:07, Rafael J. Wysocki wrote:
> > > I mean, that only means that the poor system has more pages to fault back
> > > in at resume time, before the user can even begin to think about doing
> > > anything useful.
> >
> > Well, that's not the only possibility. After we fix the memory freeing
> > issue we can use the observation that page cache pages need not be saved to
> > disk during suspend, because they already are in a storage. We only need
> > to create a map of these pages during suspend with the information on where
> > to get them from and prefetch them into memory during resume independently
> > of the page fault mechanism.
> >
> > This way we won't have to actually save anything before we snapshot the
> > system and the system should be reasonably responsive after resume.
>
> But this is going to be much more complicated than simply saving the pages in
> the first place. You'll need some mechanism for figuring out what pages to
> get, how to fault them in, etc. In addition, it will be much slower than
> simply reading them back from (ideally) contiguous storage.
It will not be *much* slower. You gain some speed by not having to
write anything, too. And done properly, it is going to be simple. Lets
see what Rafael comes up with.
[Big advantage is that /proc/list-me-pagecache can be implemented
without any dependencies on the rest of swsusp code, and is likely to
be useful for speeding up boot, etc.]
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
Hi,
On Saturday 25 February 2006 01:26, Nigel Cunningham wrote:
> On Saturday 25 February 2006 10:20, Rafael J. Wysocki wrote:
> > On Saturday 25 February 2006 00:11, Nigel Cunningham wrote:
> > > On Saturday 25 February 2006 06:22, Rafael J. Wysocki wrote:
> > > > On Friday 24 February 2006 14:12, Pavel Machek wrote:
> > > > > On Pá 24-02-06 11:58:07, Rafael J. Wysocki wrote:
> >
> > }-- snip --{
> >
> > > > > > Well, if all of the pages that Nigel saves before snapshot are
> > > > > > freeable in theory, there evidently is something wrong with freeing
> > > > > > in swsusp, as we have a testcase in which the user was unable to
> > > > > > suspend with swsusp due to the lack of memory and could suspend
> > > > > > with suspend2.
> > > > > >
> > > > > > However, the only thing in swsusp_shrink_memory() that may be wrong
> > > > > > is we return -ENOMEM as soon as shrink_all_memory() returns 0.
> > > > > > Namely, if shrink_all_memory() can return 0 prematurely (ie. "there
> > > > > > still are some freeable pages, but they could not be freed in
> > > > > > _this_ call"), we should continue until it returns 0 twice in a row
> > > > > > (or something like that). If this doesn't help, we'll have to fix
> > > > > > shrink_all_memory() I'm afraid.
> > > > >
> > > > > I did try shrink_all_memory() five times, with .5 second delay
> > > > > between them, and it freed more memory at later tries.
> > > >
> > > > I wonder if the delays are essential or if so, whether they may be
> > > > shorter than .5 sec.
> > > >
> > > > > Sometimes it even freed 0 pages at the first try.
> > > > >
> > > > > I did not push the patch because
> > > > >
> > > > > 1) it was way too ugly
> > > >
> > > > I think I can do something like that in swsusp_shrink_memory() and it
> > > > won't be very ugly.
> > > >
> > > > > 2) shrink_all_memory() should be fixed. It should not really return
> > > > > if there are more pages freeable.
> > > >
> > > > Well, that would be a long-run solution. However, until it's fixed we
> > > > can use a workaround IMHO. ;-)
> > >
> > > Isn't trying to free as much memory as you can the wrong solution anyway?
> >
> > No, it isn't. There are situations in which we would like to suspend
> > "whatever it takes" and then we should be able to free as much memory as
> > _really_ possible.
> >
> > Besides, it is supposed to work, and it doesn't, so it needs fixing.
> >
> > > I mean, that only means that the poor system has more pages to fault back
> > > in at resume time, before the user can even begin to think about doing
> > > anything useful.
> >
> > Well, that's not the only possibility. After we fix the memory freeing
> > issue we can use the observation that page cache pages need not be saved to
> > disk during suspend, because they already are in a storage. We only need
> > to create a map of these pages during suspend with the information on where
> > to get them from and prefetch them into memory during resume independently
> > of the page fault mechanism.
> >
> > This way we won't have to actually save anything before we snapshot the
> > system and the system should be reasonably responsive after resume.
>
> But this is going to be much more complicated than simply saving the pages in
> the first place. You'll need some mechanism for figuring out what pages to
> get, how to fault them in, etc.
Yes, this is going to be quite difficult indeed. Still there's a price for saving the
pages and I'd like to avoid paying it. ;-)
> In addition, it will be much slower than simply reading them back from (ideally)
> contiguous storage.
Not necessarily. These pages may come from contiguous storage areas as well.
Greetings,
Rafael
Hi.
On Saturday 25 February 2006 10:56, Rafael J. Wysocki wrote:
> On Saturday 25 February 2006 01:26, Nigel Cunningham wrote:
> > On Saturday 25 February 2006 10:20, Rafael J. Wysocki wrote:
> > > On Saturday 25 February 2006 00:11, Nigel Cunningham wrote:
> > > > On Saturday 25 February 2006 06:22, Rafael J. Wysocki wrote:
> > > > > On Friday 24 February 2006 14:12, Pavel Machek wrote:
> > > > > > On Pá 24-02-06 11:58:07, Rafael J. Wysocki wrote:
> > >
> > > }-- snip --{
> > >
> > > > > > > Well, if all of the pages that Nigel saves before snapshot are
> > > > > > > freeable in theory, there evidently is something wrong with
> > > > > > > freeing in swsusp, as we have a testcase in which the user was
> > > > > > > unable to suspend with swsusp due to the lack of memory and
> > > > > > > could suspend with suspend2.
> > > > > > >
> > > > > > > However, the only thing in swsusp_shrink_memory() that may be
> > > > > > > wrong is we return -ENOMEM as soon as shrink_all_memory()
> > > > > > > returns 0. Namely, if shrink_all_memory() can return 0
> > > > > > > prematurely (ie. "there still are some freeable pages, but they
> > > > > > > could not be freed in _this_ call"), we should continue until
> > > > > > > it returns 0 twice in a row (or something like that). If this
> > > > > > > doesn't help, we'll have to fix shrink_all_memory() I'm afraid.
> > > > > >
> > > > > > I did try shrink_all_memory() five times, with .5 second delay
> > > > > > between them, and it freed more memory at later tries.
> > > > >
> > > > > I wonder if the delays are essential or if so, whether they may be
> > > > > shorter than .5 sec.
> > > > >
> > > > > > Sometimes it even freed 0 pages at the first try.
> > > > > >
> > > > > > I did not push the patch because
> > > > > >
> > > > > > 1) it was way too ugly
> > > > >
> > > > > I think I can do something like that in swsusp_shrink_memory() and
> > > > > it won't be very ugly.
> > > > >
> > > > > > 2) shrink_all_memory() should be fixed. It should not really
> > > > > > return if there are more pages freeable.
> > > > >
> > > > > Well, that would be a long-run solution. However, until it's fixed
> > > > > we can use a workaround IMHO. ;-)
> > > >
> > > > Isn't trying to free as much memory as you can the wrong solution
> > > > anyway?
> > >
> > > No, it isn't. There are situations in which we would like to suspend
> > > "whatever it takes" and then we should be able to free as much memory
> > > as _really_ possible.
> > >
> > > Besides, it is supposed to work, and it doesn't, so it needs fixing.
> > >
> > > > I mean, that only means that the poor system has more pages to fault
> > > > back in at resume time, before the user can even begin to think about
> > > > doing anything useful.
> > >
> > > Well, that's not the only possibility. After we fix the memory freeing
> > > issue we can use the observation that page cache pages need not be
> > > saved to disk during suspend, because they already are in a storage.
> > > We only need to create a map of these pages during suspend with the
> > > information on where to get them from and prefetch them into memory
> > > during resume independently of the page fault mechanism.
> > >
> > > This way we won't have to actually save anything before we snapshot the
> > > system and the system should be reasonably responsive after resume.
> >
> > But this is going to be much more complicated than simply saving the
> > pages in the first place. You'll need some mechanism for figuring out
> > what pages to get, how to fault them in, etc.
>
> Yes, this is going to be quite difficult indeed. Still there's a price for
> saving the pages and I'd like to avoid paying it. ;-)
>
> > In addition, it will be much slower than simply reading them back from
> > (ideally) contiguous storage.
>
> Not necessarily. These pages may come from contiguous storage areas as
> well.
Oh well, I suppose we can compare once you've spent the time implementing it.
Regards,
Nigel
Hi,
On Saturday 25 February 2006 00:55, Pavel Machek wrote:
> > > I did try shrink_all_memory() five times, with .5 second delay between
> > > them, and it freed more memory at later tries.
> >
> > I wonder if the delays are essential or if so, whether they may be shorter
> > than .5 sec.
>
> I was using this with some success... (Warning, against old
> kernel). But, as I said, I consider it ugly, and it would be better to
> fix shrink_all_memory.
Appended is a patch against the current -mm. [It also makes
swsusp_shrink_memory() behave as documented for image_size = 0.
Currently, if it states there's enough free RAM to suspend, it won't bother
to free a single page.]
If anyone please can test it on a machine with less than 128 MB of RAM
and see if it helps suspend there (in particular when X is running),
and if changing the value of SHRINK_SLEEP to 200 (or more) makes
any difference, I'll appreciate it very much.
Greetings,
Rafael
---
Make swsusp_shrink_memory() try harder to free more RAM if necessary or
if the anticipated size of the image is greater than image_size.
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
kernel/power/swsusp.c | 26 ++++++++++++++++++--------
1 files changed, 18 insertions(+), 8 deletions(-)
Index: linux-2.6.16-rc4-mm2/kernel/power/swsusp.c
===================================================================
--- linux-2.6.16-rc4-mm2.orig/kernel/power/swsusp.c 2006-02-26 15:12:04.000000000 +0100
+++ linux-2.6.16-rc4-mm2/kernel/power/swsusp.c 2006-02-26 16:06:27.000000000 +0100
@@ -175,6 +175,8 @@ void free_all_swap_pages(int swap, struc
*/
#define SHRINK_BITE 10000
+#define SHRINK_RETRY 3
+#define SHRINK_SLEEP 100
int swsusp_shrink_memory(void)
{
@@ -182,6 +184,7 @@ int swsusp_shrink_memory(void)
struct zone *zone;
unsigned long pages = 0;
unsigned int i = 0;
+ int retry = SHRINK_RETRY;
char *p = "-\\|/";
printk("Shrinking memory... ");
@@ -194,14 +197,21 @@ int swsusp_shrink_memory(void)
for_each_zone (zone)
if (!is_highmem(zone))
tmp -= zone->free_pages;
- if (tmp > 0) {
- tmp = shrink_all_memory(SHRINK_BITE);
- if (!tmp)
- return -ENOMEM;
- pages += tmp;
- } else if (size > image_size / PAGE_SIZE) {
- tmp = shrink_all_memory(SHRINK_BITE);
- pages += tmp;
+ if (tmp > 0 || size > image_size / PAGE_SIZE) {
+ long freed = shrink_all_memory(SHRINK_BITE);
+
+ if (freed > 0) {
+ pages += freed;
+ tmp = freed;
+ retry = SHRINK_RETRY;
+ } else {
+ if (--retry) {
+ msleep_interruptible(SHRINK_SLEEP);
+ tmp = size;
+ } else if (tmp > 0) {
+ return -ENOMEM;
+ }
+ }
}
printk("\b%c", p[i++%4]);
} while (tmp > 0);
Hi!
> > > > I did try shrink_all_memory() five times, with .5 second delay between
> > > > them, and it freed more memory at later tries.
> > >
> > > I wonder if the delays are essential or if so, whether they may be shorter
> > > than .5 sec.
> >
> > I was using this with some success... (Warning, against old
> > kernel). But, as I said, I consider it ugly, and it would be better to
> > fix shrink_all_memory.
>
> Appended is a patch against the current -mm.
> [It also makes
> swsusp_shrink_memory() behave as documented for image_size = 0.
> Currently, if it states there's enough free RAM to suspend, it won't bother
> to free a single page.]
Could we get bugfix part separately?
Pavel
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Monday 27 February 2006 00:32, Rafael J. Wysocki wrote:
> On Sunday 26 February 2006 19:53, Pavel Machek wrote:
> > > > > > I did try shrink_all_memory() five times, with .5 second delay between
> > > > > > them, and it freed more memory at later tries.
> > > > >
> > > > > I wonder if the delays are essential or if so, whether they may be shorter
> > > > > than .5 sec.
> > > >
> > > > I was using this with some success... (Warning, against old
> > > > kernel). But, as I said, I consider it ugly, and it would be better to
> > > > fix shrink_all_memory.
> > >
> > > Appended is a patch against the current -mm.
> > > [It also makes
> > > swsusp_shrink_memory() behave as documented for image_size = 0.
> > > Currently, if it states there's enough free RAM to suspend, it won't bother
> > > to free a single page.]
> >
> > Could we get bugfix part separately?
>
> Sure. Appended is the bugfix (I haven't tested it separately yet, but I think
> it's simple enough) ...
... and this is the workaround of the "shrink_all_memory() returns 0 prematurely"
problem (not tested separately yet). [Together these patches make my box
actually free more memory when image_size = 0.]
---
Make swsusp_shrink_memory() try harder to free more RAM if necessary or
if the anticipated size of the image is greater than image_size.
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
kernel/power/swsusp.c | 13 +++++++++++--
1 files changed, 11 insertions(+), 2 deletions(-)
Index: linux-2.6.16-rc4-mm2/kernel/power/swsusp.c
===================================================================
--- linux-2.6.16-rc4-mm2.orig/kernel/power/swsusp.c 2006-02-27 00:25:34.000000000 +0100
+++ linux-2.6.16-rc4-mm2/kernel/power/swsusp.c 2006-02-27 00:28:58.000000000 +0100
@@ -175,6 +175,8 @@ void free_all_swap_pages(int swap, struc
*/
#define SHRINK_BITE 10000
+#define SHRINK_RETRY 3
+#define SHRINK_SLEEP 100
int swsusp_shrink_memory(void)
{
@@ -182,6 +184,7 @@ int swsusp_shrink_memory(void)
struct zone *zone;
unsigned long pages = 0;
unsigned int i = 0;
+ int retry = SHRINK_RETRY;
char *p = "-\\|/";
printk("Shrinking memory... ");
@@ -200,8 +203,14 @@ int swsusp_shrink_memory(void)
if (freed > 0) {
pages += freed;
tmp = freed;
- } else if (tmp > 0) {
- return -ENOMEM;
+ retry = SHRINK_RETRY;
+ } else {
+ if (--retry) {
+ msleep_interruptible(SHRINK_SLEEP);
+ tmp = size;
+ } else if (tmp > 0) {
+ return -ENOMEM;
+ }
}
}
printk("\b%c", p[i++%4]);
Hi,
On Sunday 26 February 2006 19:53, Pavel Machek wrote:
> > > > > I did try shrink_all_memory() five times, with .5 second delay between
> > > > > them, and it freed more memory at later tries.
> > > >
> > > > I wonder if the delays are essential or if so, whether they may be shorter
> > > > than .5 sec.
> > >
> > > I was using this with some success... (Warning, against old
> > > kernel). But, as I said, I consider it ugly, and it would be better to
> > > fix shrink_all_memory.
> >
> > Appended is a patch against the current -mm.
> > [It also makes
> > swsusp_shrink_memory() behave as documented for image_size = 0.
> > Currently, if it states there's enough free RAM to suspend, it won't bother
> > to free a single page.]
>
> Could we get bugfix part separately?
Sure. Appended is the bugfix (I haven't tested it separately yet, but I think
it's simple enough) ...
---
Make swsusp_shrink_memory() behave as documented when image_size = 0.
Signed-off-by: Rafael J. Wysocki <[email protected]>
---
kernel/power/swsusp.c | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
Index: linux-2.6.16-rc4-mm2/kernel/power/swsusp.c
===================================================================
--- linux-2.6.16-rc4-mm2.orig/kernel/power/swsusp.c 2006-02-26 15:12:04.000000000 +0100
+++ linux-2.6.16-rc4-mm2/kernel/power/swsusp.c 2006-02-27 00:25:34.000000000 +0100
@@ -194,14 +194,15 @@ int swsusp_shrink_memory(void)
for_each_zone (zone)
if (!is_highmem(zone))
tmp -= zone->free_pages;
- if (tmp > 0) {
- tmp = shrink_all_memory(SHRINK_BITE);
- if (!tmp)
+ if (tmp > 0 || size > image_size / PAGE_SIZE) {
+ long freed = shrink_all_memory(SHRINK_BITE);
+
+ if (freed > 0) {
+ pages += freed;
+ tmp = freed;
+ } else if (tmp > 0) {
return -ENOMEM;
- pages += tmp;
- } else if (size > image_size / PAGE_SIZE) {
- tmp = shrink_all_memory(SHRINK_BITE);
- pages += tmp;
+ }
}
printk("\b%c", p[i++%4]);
} while (tmp > 0);
On Po 27-02-06 00:32:24, Rafael J. Wysocki wrote:
> Hi,
>
> On Sunday 26 February 2006 19:53, Pavel Machek wrote:
> > > > > > I did try shrink_all_memory() five times, with .5 second delay between
> > > > > > them, and it freed more memory at later tries.
> > > > >
> > > > > I wonder if the delays are essential or if so, whether they may be shorter
> > > > > than .5 sec.
> > > >
> > > > I was using this with some success... (Warning, against old
> > > > kernel). But, as I said, I consider it ugly, and it would be better to
> > > > fix shrink_all_memory.
> > >
> > > Appended is a patch against the current -mm.
> > > [It also makes
> > > swsusp_shrink_memory() behave as documented for image_size = 0.
> > > Currently, if it states there's enough free RAM to suspend, it won't bother
> > > to free a single page.]
> >
> > Could we get bugfix part separately?
>
> Sure. Appended is the bugfix (I haven't tested it separately yet, but I think
> it's simple enough) ...
Are you sure? The way I read old code ... it looks correct to me.
size is always > 1000 or so. if image_size = 0, size >
image_size/PAGE_SIZE and we'll loop as long as shrink_all_memory()
frees something.
Pavel
printk("Shrinking memory... ");
do {
/* size = How much memory would we need if we did not
free anything? */
size = 2 * count_highmem_pages();
size += size / 50 + count_data_pages();
size += (size + PBES_PER_PAGE - 1) / PBES_PER_PAGE +
PAGES_FOR_IO;
/* tmp = How much memory do we *need* to free in order
to fit? */
tmp = size;
for_each_zone (zone)
if (!is_highmem(zone))
tmp -= zone->free_pages;
if (tmp > 0) {
tmp = shrink_all_memory(SHRINK_BITE);
if (!tmp)
return -ENOMEM;
pages += tmp;
} else if (size > image_size / PAGE_SIZE) {
tmp = shrink_all_memory(SHRINK_BITE);
pages += tmp;
}
printk("\b%c", p[i++%4]);
--
Web maintainer for suspend.sf.net (http://www.sf.net/projects/suspend) wanted...
On Po 27-02-06 00:38:40, Rafael J. Wysocki wrote:
> On Monday 27 February 2006 00:32, Rafael J. Wysocki wrote:
> > On Sunday 26 February 2006 19:53, Pavel Machek wrote:
> > > > > > > I did try shrink_all_memory() five times, with .5 second delay between
> > > > > > > them, and it freed more memory at later tries.
> > > > > >
> > > > > > I wonder if the delays are essential or if so, whether they may be shorter
> > > > > > than .5 sec.
> > > > >
> > > > > I was using this with some success... (Warning, against old
> > > > > kernel). But, as I said, I consider it ugly, and it would be better to
> > > > > fix shrink_all_memory.
> > > >
> > > > Appended is a patch against the current -mm.
> > > > [It also makes
> > > > swsusp_shrink_memory() behave as documented for image_size = 0.
> > > > Currently, if it states there's enough free RAM to suspend, it won't bother
> > > > to free a single page.]
> > >
> > > Could we get bugfix part separately?
> >
> > Sure. Appended is the bugfix (I haven't tested it separately yet, but I think
> > it's simple enough) ...
>
> ... and this is the workaround of the "shrink_all_memory() returns 0 prematurely"
> problem (not tested separately yet). [Together these patches make my box
> actually free more memory when image_size = 0.]
He he, move the workaround into mm/vmscan.c to get Andrew's attetion
then attempt to push it :-))). That way
1) shrink_all_memory() will get fixed for all callers
2) you'll probably force akpm to fix it the right way :-).
Pavel
--
Feeling evil tonight.
On Monday 27 February 2006 00:56, Pavel Machek wrote:
> On Po 27-02-06 00:38:40, Rafael J. Wysocki wrote:
> > On Monday 27 February 2006 00:32, Rafael J. Wysocki wrote:
> > > On Sunday 26 February 2006 19:53, Pavel Machek wrote:
> > > > > > > > I did try shrink_all_memory() five times, with .5 second delay between
> > > > > > > > them, and it freed more memory at later tries.
> > > > > > >
> > > > > > > I wonder if the delays are essential or if so, whether they may be shorter
> > > > > > > than .5 sec.
> > > > > >
> > > > > > I was using this with some success... (Warning, against old
> > > > > > kernel). But, as I said, I consider it ugly, and it would be better to
> > > > > > fix shrink_all_memory.
> > > > >
> > > > > Appended is a patch against the current -mm.
> > > > > [It also makes
> > > > > swsusp_shrink_memory() behave as documented for image_size = 0.
> > > > > Currently, if it states there's enough free RAM to suspend, it won't bother
> > > > > to free a single page.]
> > > >
> > > > Could we get bugfix part separately?
> > >
> > > Sure. Appended is the bugfix (I haven't tested it separately yet, but I think
> > > it's simple enough) ...
> >
> > ... and this is the workaround of the "shrink_all_memory() returns 0 prematurely"
> > problem (not tested separately yet). [Together these patches make my box
> > actually free more memory when image_size = 0.]
>
> He he, move the workaround into mm/vmscan.c to get Andrew's attetion
> then attempt to push it :-))). That way
>
> 1) shrink_all_memory() will get fixed for all callers
>
> 2) you'll probably force akpm to fix it the right way :-).
Well, it looks like there are only two users of shrink_all_memory(), swsusp.c
and kernel/power/main.c, so we can change its behavior.
I think I'll leave swsusp.c as is and change shrink_all_memory() to
"try harder". ;-)
Greetings,
Rafael
Hi,
On Monday 27 February 2006 00:52, Pavel Machek wrote:
> On Po 27-02-06 00:32:24, Rafael J. Wysocki wrote:
> > On Sunday 26 February 2006 19:53, Pavel Machek wrote:
> > > > > > > I did try shrink_all_memory() five times, with .5 second delay between
> > > > > > > them, and it freed more memory at later tries.
> > > > > >
> > > > > > I wonder if the delays are essential or if so, whether they may be shorter
> > > > > > than .5 sec.
> > > > >
> > > > > I was using this with some success... (Warning, against old
> > > > > kernel). But, as I said, I consider it ugly, and it would be better to
> > > > > fix shrink_all_memory.
> > > >
> > > > Appended is a patch against the current -mm.
> > > > [It also makes
> > > > swsusp_shrink_memory() behave as documented for image_size = 0.
> > > > Currently, if it states there's enough free RAM to suspend, it won't bother
> > > > to free a single page.]
> > >
> > > Could we get bugfix part separately?
> >
> > Sure. Appended is the bugfix (I haven't tested it separately yet, but I think
> > it's simple enough) ...
>
> Are you sure? The way I read old code ... it looks correct to me.
>
> size is always > 1000 or so. if image_size = 0, size >
> image_size/PAGE_SIZE and we'll loop as long as shrink_all_memory()
> frees something.
Of course, you are right.
So the original patch was what's needed to get the workaround in. :-)
Greetings,
Rafael