* [ 00/10] [Suspend2] Modules support. @ 2006-02-01 11:37 Nigel Cunningham 2006-02-01 11:37 ` [ 01/10] [Suspend2] kernel/power/modules.h Nigel Cunningham ` (11 more replies) 0 siblings, 12 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-01 11:37 UTC (permalink / raw) To: linux-kernel 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 <nigel@suspend2.net> -- Nigel Cunningham nigel at suspend2 dot net http://suspend2.net ^ permalink raw reply [flat|nested] 432+ messages in thread
* [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-01 11:37 [ 00/10] [Suspend2] Modules support Nigel Cunningham @ 2006-02-01 11:37 ` Nigel Cunningham 2006-02-01 12:32 ` Pekka Enberg 2006-02-01 11:37 ` [ 02/10] [Suspend2] Module (de)registration Nigel Cunningham ` (10 subsequent siblings) 11 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-01 11:37 UTC (permalink / raw) To: linux-kernel, linux-kernel 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 <nigel@suspend2.net> 0 files changed, 0 insertions(+), 0 deletions(-) -- Nigel Cunningham nigel at suspend2 dot net ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-01 11:37 ` [ 01/10] [Suspend2] kernel/power/modules.h Nigel Cunningham @ 2006-02-01 12:32 ` Pekka Enberg 2006-02-01 12:45 ` Nigel Cunningham 0 siblings, 1 reply; 432+ messages in thread From: Pekka Enberg @ 2006-02-01 12:32 UTC (permalink / raw) To: Nigel Cunningham; +Cc: linux-kernel On 2/1/06, Nigel Cunningham <nigel@suspend2.net> 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 <nigel@suspend2.net> > > 0 files changed, 0 insertions(+), 0 deletions(-) Uh, oh, where's the patch? Pekka ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-01 12:32 ` Pekka Enberg @ 2006-02-01 12:45 ` Nigel Cunningham 2006-02-01 13:01 ` Pekka Enberg 2006-02-01 17:12 ` [ 01/10] [Suspend2] kernel/power/modules.h' Randy.Dunlap 0 siblings, 2 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-01 12:45 UTC (permalink / raw) To: Pekka Enberg; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 7926 bytes --] On Wednesday 01 February 2006 22:32, Pekka Enberg wrote: > On 2/1/06, Nigel Cunningham <nigel@suspend2.net> 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 <nigel@suspend2.net> > > > > 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 <nigel@suspend2.net> --- commit a97697c4228b1f4daa0d692b373f3811bec9cb76 tree 8bf0c9e2bff6abe18ca410a14062a3e2ed8e4214 parent 424a2272be7e6858b3929bae5fbc645c35897482 author Nigel Cunningham <nigel@suspend2.net> Wed, 01 Feb 2006 22:37:48 +1000 committer root <nigel@suspend2.net> 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 <nigel@suspend2.net> + * + * 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply related [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-01 12:45 ` Nigel Cunningham @ 2006-02-01 13:01 ` Pekka Enberg 2006-02-01 21:30 ` Nigel Cunningham ` (2 more replies) 2006-02-01 17:12 ` [ 01/10] [Suspend2] kernel/power/modules.h' Randy.Dunlap 1 sibling, 3 replies; 432+ messages in thread From: Pekka Enberg @ 2006-02-01 13:01 UTC (permalink / raw) To: Nigel Cunningham; +Cc: linux-kernel On 2/1/06, Nigel Cunningham <nigel@suspend2.net> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-01 13:01 ` Pekka Enberg @ 2006-02-01 21:30 ` Nigel Cunningham 2006-02-01 21:45 ` Pekka Enberg 2006-02-02 11:35 ` Nigel Cunningham 2006-02-02 11:44 ` Nigel Cunningham 2 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-01 21:30 UTC (permalink / raw) To: Pekka Enberg; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1914 bytes --] Hi. On Wednesday 01 February 2006 23:01, Pekka Enberg wrote: > On 2/1/06, Nigel Cunningham <nigel@suspend2.net> 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-01 21:30 ` Nigel Cunningham @ 2006-02-01 21:45 ` Pekka Enberg 2006-02-01 22:55 ` Nigel Cunningham 2006-02-02 10:06 ` Pavel Machek 0 siblings, 2 replies; 432+ messages in thread From: Pekka Enberg @ 2006-02-01 21:45 UTC (permalink / raw) To: Nigel Cunningham; +Cc: linux-kernel 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 <nigel@suspend2.net> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-01 21:45 ` Pekka Enberg @ 2006-02-01 22:55 ` Nigel Cunningham 2006-02-02 8:31 ` Rafael J. Wysocki 2006-02-02 10:06 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-01 22:55 UTC (permalink / raw) To: Pekka Enberg; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1004 bytes --] 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 <nigel@suspend2.net> 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-01 22:55 ` Nigel Cunningham @ 2006-02-02 8:31 ` Rafael J. Wysocki 2006-02-02 9:22 ` Nigel Cunningham 2006-02-02 9:38 ` Pavel Machek 0 siblings, 2 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-02 8:31 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Pekka Enberg, linux-kernel, Pavel Machek 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 <nigel@suspend2.net> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 8:31 ` Rafael J. Wysocki @ 2006-02-02 9:22 ` Nigel Cunningham 2006-02-02 10:16 ` Pavel Machek 2006-02-02 13:34 ` Rafael J. Wysocki 2006-02-02 9:38 ` Pavel Machek 1 sibling, 2 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-02 9:22 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Pekka Enberg, linux-kernel, Pavel Machek [-- Attachment #1: Type: text/plain, Size: 2740 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 9:22 ` Nigel Cunningham @ 2006-02-02 10:16 ` Pavel Machek 2006-02-02 10:29 ` Nigel Cunningham 2006-02-02 13:34 ` Rafael J. Wysocki 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-02 10:16 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Rafael J. Wysocki, Pekka Enberg, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 10:16 ` Pavel Machek @ 2006-02-02 10:29 ` Nigel Cunningham 2006-02-02 10:39 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-02 10:29 UTC (permalink / raw) To: Pavel Machek; +Cc: Rafael J. Wysocki, Pekka Enberg, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1618 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 10:29 ` Nigel Cunningham @ 2006-02-02 10:39 ` Pavel Machek 2006-02-02 11:20 ` Nigel Cunningham 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-02 10:39 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Rafael J. Wysocki, Pekka Enberg, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 10:39 ` Pavel Machek @ 2006-02-02 11:20 ` Nigel Cunningham 2006-02-02 11:40 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-02 11:20 UTC (permalink / raw) To: Pavel Machek; +Cc: Rafael J. Wysocki, Pekka Enberg, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2754 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 11:20 ` Nigel Cunningham @ 2006-02-02 11:40 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-02 11:40 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Rafael J. Wysocki, Pekka Enberg, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 9:22 ` Nigel Cunningham 2006-02-02 10:16 ` Pavel Machek @ 2006-02-02 13:34 ` Rafael J. Wysocki 2006-02-02 21:27 ` Nigel Cunningham 1 sibling, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-02 13:34 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Pekka Enberg, linux-kernel, Pavel Machek 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 13:34 ` Rafael J. Wysocki @ 2006-02-02 21:27 ` Nigel Cunningham 2006-02-02 23:12 ` Rafael J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-02 21:27 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Pekka Enberg, linux-kernel, Pavel Machek [-- Attachment #1: Type: text/plain, Size: 1626 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 21:27 ` Nigel Cunningham @ 2006-02-02 23:12 ` Rafael J. Wysocki 0 siblings, 0 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-02 23:12 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Pekka Enberg, linux-kernel, Pavel Machek 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 8:31 ` Rafael J. Wysocki 2006-02-02 9:22 ` Nigel Cunningham @ 2006-02-02 9:38 ` Pavel Machek 2006-02-02 10:30 ` Nigel Cunningham 2006-02-02 12:53 ` Rafael J. Wysocki 1 sibling, 2 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-02 9:38 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Nigel Cunningham, Pekka Enberg, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 9:38 ` Pavel Machek @ 2006-02-02 10:30 ` Nigel Cunningham 2006-02-02 12:53 ` Rafael J. Wysocki 1 sibling, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-02 10:30 UTC (permalink / raw) To: Pavel Machek; +Cc: Rafael J. Wysocki, Pekka Enberg, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1227 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 9:38 ` Pavel Machek 2006-02-02 10:30 ` Nigel Cunningham @ 2006-02-02 12:53 ` Rafael J. Wysocki 2006-02-02 21:27 ` Nigel Cunningham 1 sibling, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-02 12:53 UTC (permalink / raw) To: Pavel Machek; +Cc: Nigel Cunningham, Pekka Enberg, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 12:53 ` Rafael J. Wysocki @ 2006-02-02 21:27 ` Nigel Cunningham 2006-02-02 22:10 ` Rafael J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-02 21:27 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Pavel Machek, Pekka Enberg, linux-kernel [-- Attachment #1: Type: text/plain, Size: 3342 bytes --] 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- See our web page for Howtos, FAQs, the Wiki and mailing list info. http://www.suspend2.net IRC: #suspend2 on Freenode [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 21:27 ` Nigel Cunningham @ 2006-02-02 22:10 ` Rafael J. Wysocki 2006-02-03 0:20 ` Nigel Cunningham 0 siblings, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-02 22:10 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Pavel Machek, Pekka Enberg, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 22:10 ` Rafael J. Wysocki @ 2006-02-03 0:20 ` Nigel Cunningham 2006-02-03 8:57 ` Rafael J. Wysocki 2006-02-03 13:16 ` Pavel Machek 0 siblings, 2 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-03 0:20 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Pavel Machek, Pekka Enberg, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2149 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-03 0:20 ` Nigel Cunningham @ 2006-02-03 8:57 ` Rafael J. Wysocki 2006-02-03 11:47 ` Nigel Cunningham 2006-02-03 13:16 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-03 8:57 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Pavel Machek, Pekka Enberg, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-03 8:57 ` Rafael J. Wysocki @ 2006-02-03 11:47 ` Nigel Cunningham 2006-02-03 22:52 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-03 11:47 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Pavel Machek, Pekka Enberg, linux-kernel [-- Attachment #1: Type: text/plain, Size: 7857 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-03 11:47 ` Nigel Cunningham @ 2006-02-03 22:52 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-03 22:52 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Rafael J. Wysocki, Pekka Enberg, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-03 0:20 ` Nigel Cunningham 2006-02-03 8:57 ` Rafael J. Wysocki @ 2006-02-03 13:16 ` Pavel Machek 2006-02-03 13:41 ` Nigel Cunningham 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-03 13:16 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Rafael J. Wysocki, Pekka Enberg, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-03 13:16 ` Pavel Machek @ 2006-02-03 13:41 ` Nigel Cunningham 2006-02-03 23:45 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-03 13:41 UTC (permalink / raw) To: Pavel Machek; +Cc: Rafael J. Wysocki, Pekka Enberg, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2686 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-03 13:41 ` Nigel Cunningham @ 2006-02-03 23:45 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-03 23:45 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Rafael J. Wysocki, Pekka Enberg, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-01 21:45 ` Pekka Enberg 2006-02-01 22:55 ` Nigel Cunningham @ 2006-02-02 10:06 ` Pavel Machek 2006-02-02 10:57 ` Pekka Enberg 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-02 10:06 UTC (permalink / raw) To: Pekka Enberg; +Cc: Nigel Cunningham, linux-kernel 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 <nigel@suspend2.net> 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 10:06 ` Pavel Machek @ 2006-02-02 10:57 ` Pekka Enberg 2006-02-02 11:02 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Pekka Enberg @ 2006-02-02 10:57 UTC (permalink / raw) To: Pavel Machek; +Cc: Nigel Cunningham, linux-kernel 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 <pavel@ucw.cz> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 10:57 ` Pekka Enberg @ 2006-02-02 11:02 ` Pavel Machek 2006-02-02 11:16 ` Pekka Enberg 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-02 11:02 UTC (permalink / raw) To: Pekka Enberg; +Cc: Nigel Cunningham, linux-kernel 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 <pavel@ucw.cz> 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 11:02 ` Pavel Machek @ 2006-02-02 11:16 ` Pekka Enberg 2006-02-02 11:39 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Pekka Enberg @ 2006-02-02 11:16 UTC (permalink / raw) To: Pavel Machek; +Cc: Nigel Cunningham, linux-kernel 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 <pavel@ucw.cz> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 11:16 ` Pekka Enberg @ 2006-02-02 11:39 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-02 11:39 UTC (permalink / raw) To: Pekka Enberg; +Cc: Nigel Cunningham, linux-kernel 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 <pavel@ucw.cz> 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-01 13:01 ` Pekka Enberg 2006-02-01 21:30 ` Nigel Cunningham @ 2006-02-02 11:35 ` Nigel Cunningham 2006-02-02 11:44 ` Nigel Cunningham 2 siblings, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-02 11:35 UTC (permalink / raw) To: Pekka Enberg; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1774 bytes --] Hi. On Wednesday 01 February 2006 23:01, Pekka Enberg wrote: > On 2/1/06, Nigel Cunningham <nigel@suspend2.net> 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-01 13:01 ` Pekka Enberg 2006-02-01 21:30 ` Nigel Cunningham 2006-02-02 11:35 ` Nigel Cunningham @ 2006-02-02 11:44 ` Nigel Cunningham 2006-02-02 12:48 ` Pekka J Enberg 2 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-02 11:44 UTC (permalink / raw) To: Pekka Enberg; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 896 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 11:44 ` Nigel Cunningham @ 2006-02-02 12:48 ` Pekka J Enberg 2006-02-02 21:27 ` Nigel Cunningham 0 siblings, 1 reply; 432+ messages in thread From: Pekka J Enberg @ 2006-02-02 12:48 UTC (permalink / raw) To: Nigel Cunningham; +Cc: linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h 2006-02-02 12:48 ` Pekka J Enberg @ 2006-02-02 21:27 ` Nigel Cunningham 0 siblings, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-02 21:27 UTC (permalink / raw) To: Pekka J Enberg; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1470 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h' 2006-02-01 12:45 ` Nigel Cunningham 2006-02-01 13:01 ` Pekka Enberg @ 2006-02-01 17:12 ` Randy.Dunlap 2006-02-01 21:31 ` Nigel Cunningham 2006-02-02 11:35 ` Nigel Cunningham 1 sibling, 2 replies; 432+ messages in thread From: Randy.Dunlap @ 2006-02-01 17:12 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Pekka Enberg, linux-kernel On Wed, 1 Feb 2006, Nigel Cunningham wrote: > On Wednesday 01 February 2006 22:32, Pekka Enberg wrote: > > On 2/1/06, Nigel Cunningham <nigel@suspend2.net> 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 <nigel@suspend2.net> > > > > > > 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h' 2006-02-01 17:12 ` [ 01/10] [Suspend2] kernel/power/modules.h' Randy.Dunlap @ 2006-02-01 21:31 ` Nigel Cunningham 2006-02-02 11:35 ` Nigel Cunningham 1 sibling, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-01 21:31 UTC (permalink / raw) To: Randy.Dunlap; +Cc: Pekka Enberg, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1855 bytes --] 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 <nigel@suspend2.net> 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 <nigel@suspend2.net> > > > > > > > > 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 01/10] [Suspend2] kernel/power/modules.h' 2006-02-01 17:12 ` [ 01/10] [Suspend2] kernel/power/modules.h' Randy.Dunlap 2006-02-01 21:31 ` Nigel Cunningham @ 2006-02-02 11:35 ` Nigel Cunningham 1 sibling, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-02 11:35 UTC (permalink / raw) To: Randy.Dunlap; +Cc: Pekka Enberg, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1777 bytes --] 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 <nigel@suspend2.net> 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 <nigel@suspend2.net> > > > > > > > > 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* [ 02/10] [Suspend2] Module (de)registration. 2006-02-01 11:37 [ 00/10] [Suspend2] Modules support Nigel Cunningham 2006-02-01 11:37 ` [ 01/10] [Suspend2] kernel/power/modules.h Nigel Cunningham @ 2006-02-01 11:37 ` Nigel Cunningham 2006-02-01 12:37 ` Pekka Enberg 2006-02-01 11:37 ` [ 03/10] [Suspend2] Move module to the tail of lists Nigel Cunningham ` (9 subsequent siblings) 11 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-01 11:37 UTC (permalink / raw) To: linux-kernel, linux-kernel This patch implements registration and deregistration of modules that are used for page transformation and storage. Signed-off-by: Nigel Cunningham <nigel@suspend2.net> 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 <nigel@suspend2.net> + * + */ + +#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 ^ permalink raw reply related [flat|nested] 432+ messages in thread
* Re: [ 02/10] [Suspend2] Module (de)registration. 2006-02-01 11:37 ` [ 02/10] [Suspend2] Module (de)registration Nigel Cunningham @ 2006-02-01 12:37 ` Pekka Enberg 2006-02-01 12:47 ` Nigel Cunningham 0 siblings, 1 reply; 432+ messages in thread From: Pekka Enberg @ 2006-02-01 12:37 UTC (permalink / raw) To: Nigel Cunningham; +Cc: linux-kernel Hi, On 2/1/06, Nigel Cunningham <nigel@suspend2.net> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 02/10] [Suspend2] Module (de)registration. 2006-02-01 12:37 ` Pekka Enberg @ 2006-02-01 12:47 ` Nigel Cunningham 2006-02-02 9:54 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-01 12:47 UTC (permalink / raw) To: Pekka Enberg; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1166 bytes --] Hi. On Wednesday 01 February 2006 22:37, Pekka Enberg wrote: > Hi, > > On 2/1/06, Nigel Cunningham <nigel@suspend2.net> 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- See our web page for Howtos, FAQs, the Wiki and mailing list info. http://www.suspend2.net IRC: #suspend2 on Freenode [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 02/10] [Suspend2] Module (de)registration. 2006-02-01 12:47 ` Nigel Cunningham @ 2006-02-02 9:54 ` Pavel Machek 2006-02-02 10:33 ` Nigel Cunningham 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-02 9:54 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Pekka Enberg, linux-kernel 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 <nigel@suspend2.net> 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 02/10] [Suspend2] Module (de)registration. 2006-02-02 9:54 ` Pavel Machek @ 2006-02-02 10:33 ` Nigel Cunningham 0 siblings, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-02 10:33 UTC (permalink / raw) To: Pavel Machek; +Cc: Pekka Enberg, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1281 bytes --] 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 <nigel@suspend2.net> 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* [ 03/10] [Suspend2] Move module to the tail of lists. 2006-02-01 11:37 [ 00/10] [Suspend2] Modules support Nigel Cunningham 2006-02-01 11:37 ` [ 01/10] [Suspend2] kernel/power/modules.h Nigel Cunningham 2006-02-01 11:37 ` [ 02/10] [Suspend2] Module (de)registration Nigel Cunningham @ 2006-02-01 11:37 ` Nigel Cunningham 2006-02-01 11:37 ` [ 04/10] [Suspend2] Module initialise/cleanup Nigel Cunningham ` (8 subsequent siblings) 11 siblings, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-01 11:37 UTC (permalink / raw) To: linux-kernel, linux-kernel 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 <nigel@suspend2.net> 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 ^ permalink raw reply related [flat|nested] 432+ messages in thread
* [ 04/10] [Suspend2] Module initialise/cleanup. 2006-02-01 11:37 [ 00/10] [Suspend2] Modules support Nigel Cunningham ` (2 preceding siblings ...) 2006-02-01 11:37 ` [ 03/10] [Suspend2] Move module to the tail of lists Nigel Cunningham @ 2006-02-01 11:37 ` Nigel Cunningham 2006-02-01 11:37 ` [ 05/10] [Suspend2] Get next module Nigel Cunningham ` (7 subsequent siblings) 11 siblings, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-01 11:37 UTC (permalink / raw) To: linux-kernel, linux-kernel 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 <nigel@suspend2.net> 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 ^ permalink raw reply related [flat|nested] 432+ messages in thread
* [ 05/10] [Suspend2] Get next module. 2006-02-01 11:37 [ 00/10] [Suspend2] Modules support Nigel Cunningham ` (3 preceding siblings ...) 2006-02-01 11:37 ` [ 04/10] [Suspend2] Module initialise/cleanup Nigel Cunningham @ 2006-02-01 11:37 ` Nigel Cunningham 2006-02-01 11:37 ` [ 06/10] [Suspend2] Get/put module reference Nigel Cunningham ` (6 subsequent siblings) 11 siblings, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-01 11:37 UTC (permalink / raw) To: linux-kernel, linux-kernel Given a current (possibly NULL) pointer to a module, find the next module in the pipeline. Signed-off-by: Nigel Cunningham <nigel@suspend2.net> 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 ^ permalink raw reply related [flat|nested] 432+ messages in thread
* [ 06/10] [Suspend2] Get/put module reference. 2006-02-01 11:37 [ 00/10] [Suspend2] Modules support Nigel Cunningham ` (4 preceding siblings ...) 2006-02-01 11:37 ` [ 05/10] [Suspend2] Get next module Nigel Cunningham @ 2006-02-01 11:37 ` Nigel Cunningham 2006-02-01 11:37 ` [ 07/10] [Suspend2] Header storage for modules Nigel Cunningham ` (5 subsequent siblings) 11 siblings, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-01 11:37 UTC (permalink / raw) To: linux-kernel, linux-kernel Take or put a reference to a module, so it can't be unloaded while in use. Signed-off-by: Nigel Cunningham <nigel@suspend2.net> 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 ^ permalink raw reply related [flat|nested] 432+ messages in thread
* [ 07/10] [Suspend2] Header storage for modules. 2006-02-01 11:37 [ 00/10] [Suspend2] Modules support Nigel Cunningham ` (5 preceding siblings ...) 2006-02-01 11:37 ` [ 06/10] [Suspend2] Get/put module reference Nigel Cunningham @ 2006-02-01 11:37 ` Nigel Cunningham 2006-02-01 11:37 ` [ 08/10] [Suspend2] Find a module given its name Nigel Cunningham ` (4 subsequent siblings) 11 siblings, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-01 11:37 UTC (permalink / raw) To: linux-kernel, linux-kernel Calculate the space in an image header required for storing module configuration data. Signed-off-by: Nigel Cunningham <nigel@suspend2.net> 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 ^ permalink raw reply related [flat|nested] 432+ messages in thread
* [ 08/10] [Suspend2] Find a module given its name 2006-02-01 11:37 [ 00/10] [Suspend2] Modules support Nigel Cunningham ` (6 preceding siblings ...) 2006-02-01 11:37 ` [ 07/10] [Suspend2] Header storage for modules Nigel Cunningham @ 2006-02-01 11:37 ` Nigel Cunningham 2006-02-01 11:37 ` [ 09/10] [Suspend2] Append module debug info to a buffer Nigel Cunningham ` (3 subsequent siblings) 11 siblings, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-01 11:37 UTC (permalink / raw) To: linux-kernel, linux-kernel 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 <nigel@suspend2.net> 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 ^ permalink raw reply related [flat|nested] 432+ messages in thread
* [ 09/10] [Suspend2] Append module debug info to a buffer. 2006-02-01 11:37 [ 00/10] [Suspend2] Modules support Nigel Cunningham ` (7 preceding siblings ...) 2006-02-01 11:37 ` [ 08/10] [Suspend2] Find a module given its name Nigel Cunningham @ 2006-02-01 11:37 ` Nigel Cunningham 2006-02-01 11:37 ` [ 10/10] [Suspend2] Memory needed for modules Nigel Cunningham ` (2 subsequent siblings) 11 siblings, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-01 11:37 UTC (permalink / raw) To: linux-kernel, linux-kernel 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 <nigel@suspend2.net> 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 ^ permalink raw reply related [flat|nested] 432+ messages in thread
* [ 10/10] [Suspend2] Memory needed for modules. 2006-02-01 11:37 [ 00/10] [Suspend2] Modules support Nigel Cunningham ` (8 preceding siblings ...) 2006-02-01 11:37 ` [ 09/10] [Suspend2] Append module debug info to a buffer Nigel Cunningham @ 2006-02-01 11:37 ` Nigel Cunningham 2006-02-01 12:38 ` [ 00/10] [Suspend2] Modules support Pekka Enberg 2006-02-02 10:05 ` Pavel Machek 11 siblings, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-01 11:37 UTC (permalink / raw) To: linux-kernel, linux-kernel 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 <nigel@suspend2.net> 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 ^ permalink raw reply related [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-01 11:37 [ 00/10] [Suspend2] Modules support Nigel Cunningham ` (9 preceding siblings ...) 2006-02-01 11:37 ` [ 10/10] [Suspend2] Memory needed for modules Nigel Cunningham @ 2006-02-01 12:38 ` Pekka Enberg 2006-02-01 12:49 ` Nigel Cunningham 2006-02-02 10:05 ` Pavel Machek 11 siblings, 1 reply; 432+ messages in thread From: Pekka Enberg @ 2006-02-01 12:38 UTC (permalink / raw) To: Nigel Cunningham; +Cc: linux-kernel On 2/1/06, Nigel Cunningham <nigel@suspend2.net> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-01 12:38 ` [ 00/10] [Suspend2] Modules support Pekka Enberg @ 2006-02-01 12:49 ` Nigel Cunningham 0 siblings, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-01 12:49 UTC (permalink / raw) To: Pekka Enberg; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 798 bytes --] Hi. On Wednesday 01 February 2006 22:38, Pekka Enberg wrote: > On 2/1/06, Nigel Cunningham <nigel@suspend2.net> 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-01 11:37 [ 00/10] [Suspend2] Modules support Nigel Cunningham ` (10 preceding siblings ...) 2006-02-01 12:38 ` [ 00/10] [Suspend2] Modules support Pekka Enberg @ 2006-02-02 10:05 ` Pavel Machek 2006-02-02 10:38 ` Nigel Cunningham 11 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-02 10:05 UTC (permalink / raw) To: Nigel Cunningham; +Cc: linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 10:05 ` Pavel Machek @ 2006-02-02 10:38 ` Nigel Cunningham 2006-02-02 10:47 ` Pavel Machek 2006-02-02 10:48 ` Pavel Machek 0 siblings, 2 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-02 10:38 UTC (permalink / raw) To: Pavel Machek; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 872 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 10:38 ` Nigel Cunningham @ 2006-02-02 10:47 ` Pavel Machek 2006-02-02 11:31 ` Nigel Cunningham 2006-02-02 10:48 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-02 10:47 UTC (permalink / raw) To: Nigel Cunningham; +Cc: linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 10:47 ` Pavel Machek @ 2006-02-02 11:31 ` Nigel Cunningham 2006-02-02 11:44 ` Pekka Enberg 2006-02-02 11:59 ` Pavel Machek 0 siblings, 2 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-02 11:31 UTC (permalink / raw) To: Pavel Machek; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 1547 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 11:31 ` Nigel Cunningham @ 2006-02-02 11:44 ` Pekka Enberg 2006-02-02 12:28 ` Nigel Cunningham 2006-02-02 11:59 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Pekka Enberg @ 2006-02-02 11:44 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Pavel Machek, linux-kernel Hi, On 2/2/06, Nigel Cunningham <nigel@suspend2.net> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 11:44 ` Pekka Enberg @ 2006-02-02 12:28 ` Nigel Cunningham 2006-02-02 13:26 ` Pekka J Enberg ` (2 more replies) 0 siblings, 3 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-02 12:28 UTC (permalink / raw) To: Pekka Enberg; +Cc: Pavel Machek, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1566 bytes --] Hi. On Thursday 02 February 2006 21:44, Pekka Enberg wrote: > Hi, > > On 2/2/06, Nigel Cunningham <nigel@suspend2.net> 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 12:28 ` Nigel Cunningham @ 2006-02-02 13:26 ` Pekka J Enberg 2006-02-02 15:14 ` Pavel Machek 2006-02-02 15:43 ` Olivier Galibert 2 siblings, 0 replies; 432+ messages in thread From: Pekka J Enberg @ 2006-02-02 13:26 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Pavel Machek, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 12:28 ` Nigel Cunningham 2006-02-02 13:26 ` Pekka J Enberg @ 2006-02-02 15:14 ` Pavel Machek 2006-02-02 15:43 ` Olivier Galibert 2 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-02 15:14 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Pekka Enberg, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 12:28 ` Nigel Cunningham 2006-02-02 13:26 ` Pekka J Enberg 2006-02-02 15:14 ` Pavel Machek @ 2006-02-02 15:43 ` Olivier Galibert 2006-02-02 20:25 ` Pavel Machek 2 siblings, 1 reply; 432+ messages in thread From: Olivier Galibert @ 2006-02-02 15:43 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Pekka Enberg, Pavel Machek, linux-kernel 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 15:43 ` Olivier Galibert @ 2006-02-02 20:25 ` Pavel Machek 2006-02-02 20:31 ` Dave Jones 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-02 20:25 UTC (permalink / raw) To: Olivier Galibert, Nigel Cunningham, Pekka Enberg, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 20:25 ` Pavel Machek @ 2006-02-02 20:31 ` Dave Jones 2006-02-02 20:51 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Dave Jones @ 2006-02-02 20:31 UTC (permalink / raw) To: Pavel Machek Cc: Olivier Galibert, Nigel Cunningham, Pekka Enberg, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 20:31 ` Dave Jones @ 2006-02-02 20:51 ` Pavel Machek 2006-02-03 1:18 ` Olivier Galibert 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-02 20:51 UTC (permalink / raw) To: Dave Jones, Olivier Galibert, Nigel Cunningham, Pekka Enberg, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 20:51 ` Pavel Machek @ 2006-02-03 1:18 ` Olivier Galibert 2006-02-03 10:41 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Olivier Galibert @ 2006-02-03 1:18 UTC (permalink / raw) To: Pavel Machek; +Cc: Dave Jones, Nigel Cunningham, Pekka Enberg, linux-kernel 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 1:18 ` Olivier Galibert @ 2006-02-03 10:41 ` Pavel Machek 2006-02-03 14:29 ` Olivier Galibert 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-03 10:41 UTC (permalink / raw) To: Olivier Galibert, Dave Jones, Nigel Cunningham, Pekka Enberg, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 10:41 ` Pavel Machek @ 2006-02-03 14:29 ` Olivier Galibert 2006-02-03 17:24 ` Rafael J. Wysocki 2006-02-03 22:36 ` Pavel Machek 0 siblings, 2 replies; 432+ messages in thread From: Olivier Galibert @ 2006-02-03 14:29 UTC (permalink / raw) To: Pavel Machek; +Cc: Dave Jones, Nigel Cunningham, Pekka Enberg, linux-kernel 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 14:29 ` Olivier Galibert @ 2006-02-03 17:24 ` Rafael J. Wysocki 2006-02-03 18:30 ` Olivier Galibert 2006-02-03 22:36 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-03 17:24 UTC (permalink / raw) To: Olivier Galibert Cc: Pavel Machek, Dave Jones, Nigel Cunningham, Pekka Enberg, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 17:24 ` Rafael J. Wysocki @ 2006-02-03 18:30 ` Olivier Galibert 2006-02-03 21:08 ` Rafael J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Olivier Galibert @ 2006-02-03 18:30 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Pavel Machek, Dave Jones, Nigel Cunningham, Pekka Enberg, linux-kernel 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 18:30 ` Olivier Galibert @ 2006-02-03 21:08 ` Rafael J. Wysocki 2006-02-04 0:26 ` Olivier Galibert 0 siblings, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-03 21:08 UTC (permalink / raw) To: Olivier Galibert Cc: Pavel Machek, Dave Jones, Nigel Cunningham, Pekka Enberg, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 21:08 ` Rafael J. Wysocki @ 2006-02-04 0:26 ` Olivier Galibert 2006-02-04 0:44 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Olivier Galibert @ 2006-02-04 0:26 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Pavel Machek, Dave Jones, Nigel Cunningham, Pekka Enberg, linux-kernel 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 0:26 ` Olivier Galibert @ 2006-02-04 0:44 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-04 0:44 UTC (permalink / raw) To: Olivier Galibert, Rafael J. Wysocki, Dave Jones, Nigel Cunningham, Pekka Enberg, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 14:29 ` Olivier Galibert 2006-02-03 17:24 ` Rafael J. Wysocki @ 2006-02-03 22:36 ` Pavel Machek 1 sibling, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-03 22:36 UTC (permalink / raw) To: Olivier Galibert, Dave Jones, Nigel Cunningham, Pekka Enberg, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 11:31 ` Nigel Cunningham 2006-02-02 11:44 ` Pekka Enberg @ 2006-02-02 11:59 ` Pavel Machek 2006-02-02 12:14 ` Nigel Cunningham 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-02 11:59 UTC (permalink / raw) To: Nigel Cunningham; +Cc: linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 11:59 ` Pavel Machek @ 2006-02-02 12:14 ` Nigel Cunningham 2006-02-02 15:23 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-02 12:14 UTC (permalink / raw) To: Pavel Machek, Andrew Morton, Linus Torvalds; +Cc: linux-kernel [-- Attachment #1: Type: text/plain, Size: 3344 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 12:14 ` Nigel Cunningham @ 2006-02-02 15:23 ` Pavel Machek 2006-02-02 21:27 ` Andrew Morton 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-02 15:23 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Andrew Morton, Linus Torvalds, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 15:23 ` Pavel Machek @ 2006-02-02 21:27 ` Andrew Morton 2006-02-02 21:34 ` Lee Revell ` (5 more replies) 0 siblings, 6 replies; 432+ messages in thread From: Andrew Morton @ 2006-02-02 21:27 UTC (permalink / raw) To: Pavel Machek; +Cc: nigel, torvalds, linux-kernel Pavel Machek <pavel@ucw.cz> 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? ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 21:27 ` Andrew Morton @ 2006-02-02 21:34 ` Lee Revell 2006-02-02 22:23 ` Andrew Morton 2006-02-02 22:54 ` Nigel Cunningham 2006-02-02 23:10 ` Rafael J. Wysocki ` (4 subsequent siblings) 5 siblings, 2 replies; 432+ messages in thread From: Lee Revell @ 2006-02-02 21:34 UTC (permalink / raw) To: Andrew Morton; +Cc: Pavel Machek, nigel, torvalds, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 21:34 ` Lee Revell @ 2006-02-02 22:23 ` Andrew Morton 2006-02-02 22:29 ` Lee Revell 2006-02-03 10:51 ` Pavel Machek 2006-02-02 22:54 ` Nigel Cunningham 1 sibling, 2 replies; 432+ messages in thread From: Andrew Morton @ 2006-02-02 22:23 UTC (permalink / raw) To: Lee Revell; +Cc: pavel, nigel, torvalds, linux-kernel Lee Revell <rlrevell@joe-job.com> 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). ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 22:23 ` Andrew Morton @ 2006-02-02 22:29 ` Lee Revell 2006-02-02 22:48 ` Andrew Morton ` (2 more replies) 2006-02-03 10:51 ` Pavel Machek 1 sibling, 3 replies; 432+ messages in thread From: Lee Revell @ 2006-02-02 22:29 UTC (permalink / raw) To: Andrew Morton; +Cc: pavel, nigel, torvalds, linux-kernel On Thu, 2006-02-02 at 14:23 -0800, Andrew Morton wrote: > Lee Revell <rlrevell@joe-job.com> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 22:29 ` Lee Revell @ 2006-02-02 22:48 ` Andrew Morton 2006-02-03 1:48 ` Olivier Galibert 2006-02-03 9:49 ` Matthew Garrett 2 siblings, 0 replies; 432+ messages in thread From: Andrew Morton @ 2006-02-02 22:48 UTC (permalink / raw) To: Lee Revell; +Cc: pavel, nigel, torvalds, linux-kernel, Dave Jones Lee Revell <rlrevell@joe-job.com> wrote: > > On Thu, 2006-02-02 at 14:23 -0800, Andrew Morton wrote: > > Lee Revell <rlrevell@joe-job.com> 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? ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 22:29 ` Lee Revell 2006-02-02 22:48 ` Andrew Morton @ 2006-02-03 1:48 ` Olivier Galibert 2006-02-03 6:49 ` Nigel Cunningham 2006-02-03 10:58 ` Pavel Machek 2006-02-03 9:49 ` Matthew Garrett 2 siblings, 2 replies; 432+ messages in thread From: Olivier Galibert @ 2006-02-03 1:48 UTC (permalink / raw) To: Lee Revell; +Cc: Andrew Morton, pavel, nigel, torvalds, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 1:48 ` Olivier Galibert @ 2006-02-03 6:49 ` Nigel Cunningham 2006-02-03 10:58 ` Pavel Machek 1 sibling, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-03 6:49 UTC (permalink / raw) To: Olivier Galibert, Olivier Galibert Cc: Lee Revell, Andrew Morton, pavel, torvalds, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2258 bytes --] 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- See our web page for Howtos, FAQs, the Wiki and mailing list info. http://www.suspend2.net IRC: #suspend2 on Freenode [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 1:48 ` Olivier Galibert 2006-02-03 6:49 ` Nigel Cunningham @ 2006-02-03 10:58 ` Pavel Machek 1 sibling, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-03 10:58 UTC (permalink / raw) To: Olivier Galibert, Lee Revell, Andrew Morton, nigel, torvalds, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 22:29 ` Lee Revell 2006-02-02 22:48 ` Andrew Morton 2006-02-03 1:48 ` Olivier Galibert @ 2006-02-03 9:49 ` Matthew Garrett 2006-02-03 10:23 ` Andrew Morton 2006-02-03 11:08 ` Pavel Machek 2 siblings, 2 replies; 432+ messages in thread From: Matthew Garrett @ 2006-02-03 9:49 UTC (permalink / raw) To: Lee Revell; +Cc: pavel, nigel, torvalds, linux-kernel, Andrew Morton Lee Revell <rlrevell@joe-job.com> 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 | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 9:49 ` Matthew Garrett @ 2006-02-03 10:23 ` Andrew Morton 2006-02-03 10:43 ` Matthew Garrett 2006-02-03 15:53 ` Dave Jones 2006-02-03 11:08 ` Pavel Machek 1 sibling, 2 replies; 432+ messages in thread From: Andrew Morton @ 2006-02-03 10:23 UTC (permalink / raw) To: Matthew Garrett; +Cc: rlrevell, pavel, nigel, torvalds, linux-kernel Matthew Garrett <mgarrett@chiark.greenend.org.uk> 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 10:23 ` Andrew Morton @ 2006-02-03 10:43 ` Matthew Garrett 2006-02-03 15:53 ` Dave Jones 1 sibling, 0 replies; 432+ messages in thread From: Matthew Garrett @ 2006-02-03 10:43 UTC (permalink / raw) To: Andrew Morton; +Cc: rlrevell, pavel, nigel, torvalds, linux-kernel Andrew Morton <akpm@osdl.org> 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 | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 10:23 ` Andrew Morton 2006-02-03 10:43 ` Matthew Garrett @ 2006-02-03 15:53 ` Dave Jones 1 sibling, 0 replies; 432+ messages in thread From: Dave Jones @ 2006-02-03 15:53 UTC (permalink / raw) To: Andrew Morton Cc: Matthew Garrett, rlrevell, pavel, nigel, torvalds, linux-kernel On Fri, Feb 03, 2006 at 02:23:05AM -0800, Andrew Morton wrote: > Matthew Garrett <mgarrett@chiark.greenend.org.uk> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 9:49 ` Matthew Garrett 2006-02-03 10:23 ` Andrew Morton @ 2006-02-03 11:08 ` Pavel Machek 1 sibling, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-03 11:08 UTC (permalink / raw) To: Matthew Garrett, seife Cc: Lee Revell, nigel, torvalds, linux-kernel, Andrew Morton On Pá 03-02-06 09:49:33, Matthew Garrett wrote: > Lee Revell <rlrevell@joe-job.com> 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 22:23 ` Andrew Morton 2006-02-02 22:29 ` Lee Revell @ 2006-02-03 10:51 ` Pavel Machek [not found] ` <58cb370e0602030322u4c2c9f9bm21a38be6d35d2ea6@mail.gmail.com> 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-03 10:51 UTC (permalink / raw) To: Andrew Morton; +Cc: Lee Revell, nigel, torvalds, linux-kernel On Čt 02-02-06 14:23:23, Andrew Morton wrote: > Lee Revell <rlrevell@joe-job.com> 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
[parent not found: <58cb370e0602030322u4c2c9f9bm21a38be6d35d2ea6@mail.gmail.com>]
* Re: [ 00/10] [Suspend2] Modules support. [not found] ` <58cb370e0602030322u4c2c9f9bm21a38be6d35d2ea6@mail.gmail.com> @ 2006-02-03 11:35 ` Pavel Machek 2006-02-03 13:46 ` Bartlomiej Zolnierkiewicz 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-03 11:35 UTC (permalink / raw) To: Bartlomiej Zolnierkiewicz Cc: Andrew Morton, Lee Revell, nigel, torvalds, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 11:35 ` Pavel Machek @ 2006-02-03 13:46 ` Bartlomiej Zolnierkiewicz 2006-02-03 14:10 ` Matthew Garrett 0 siblings, 1 reply; 432+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2006-02-03 13:46 UTC (permalink / raw) To: Pavel Machek; +Cc: Andrew Morton, Lee Revell, nigel, torvalds, linux-kernel On 2/3/06, Pavel Machek <pavel@ucw.cz> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 13:46 ` Bartlomiej Zolnierkiewicz @ 2006-02-03 14:10 ` Matthew Garrett 2006-02-03 14:32 ` Bartlomiej Zolnierkiewicz 0 siblings, 1 reply; 432+ messages in thread From: Matthew Garrett @ 2006-02-03 14:10 UTC (permalink / raw) To: Bartlomiej Zolnierkiewicz Cc: Andrew Morton, Lee Revell, nigel, torvalds, linux-kernel, Pavel Machek Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> 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 | mjg59-chiark.mail.linux-rutgers.kernel@srcf.ucam.org ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 14:10 ` Matthew Garrett @ 2006-02-03 14:32 ` Bartlomiej Zolnierkiewicz 2006-02-03 16:34 ` Randy.Dunlap 0 siblings, 1 reply; 432+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2006-02-03 14:32 UTC (permalink / raw) To: Matthew Garrett Cc: Andrew Morton, Lee Revell, nigel, torvalds, linux-kernel, Pavel Machek, Shaohua Li On 2/3/06, Matthew Garrett <mgarrett@chiark.greenend.org.uk> wrote: > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 14:32 ` Bartlomiej Zolnierkiewicz @ 2006-02-03 16:34 ` Randy.Dunlap 2006-02-03 16:44 ` Bartlomiej Zolnierkiewicz 0 siblings, 1 reply; 432+ messages in thread From: Randy.Dunlap @ 2006-02-03 16:34 UTC (permalink / raw) To: Bartlomiej Zolnierkiewicz Cc: Matthew Garrett, Andrew Morton, Lee Revell, nigel, torvalds, linux-kernel, Pavel Machek, Shaohua Li On Fri, 3 Feb 2006, Bartlomiej Zolnierkiewicz wrote: > On 2/3/06, Matthew Garrett <mgarrett@chiark.greenend.org.uk> wrote: > > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> 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 <shaohua.li@intel.com>. 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 16:34 ` Randy.Dunlap @ 2006-02-03 16:44 ` Bartlomiej Zolnierkiewicz 2006-02-03 16:57 ` Randy.Dunlap 0 siblings, 1 reply; 432+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2006-02-03 16:44 UTC (permalink / raw) To: Randy.Dunlap Cc: Matthew Garrett, Andrew Morton, Lee Revell, nigel, torvalds, linux-kernel, Pavel Machek, Shaohua Li On 2/3/06, Randy.Dunlap <rdunlap@xenotime.net> wrote: > On Fri, 3 Feb 2006, Bartlomiej Zolnierkiewicz wrote: > > > On 2/3/06, Matthew Garrett <mgarrett@chiark.greenend.org.uk> wrote: > > > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> 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 <shaohua.li@intel.com>. 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 16:44 ` Bartlomiej Zolnierkiewicz @ 2006-02-03 16:57 ` Randy.Dunlap 2006-02-03 18:46 ` Bartlomiej Zolnierkiewicz 0 siblings, 1 reply; 432+ messages in thread From: Randy.Dunlap @ 2006-02-03 16:57 UTC (permalink / raw) To: Bartlomiej Zolnierkiewicz Cc: Randy.Dunlap, Matthew Garrett, Andrew Morton, Lee Revell, nigel, torvalds, linux-kernel, Pavel Machek, Shaohua Li On Fri, 3 Feb 2006, Bartlomiej Zolnierkiewicz wrote: > On 2/3/06, Randy.Dunlap <rdunlap@xenotime.net> wrote: > > On Fri, 3 Feb 2006, Bartlomiej Zolnierkiewicz wrote: > > > > > On 2/3/06, Matthew Garrett <mgarrett@chiark.greenend.org.uk> wrote: > > > > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> 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 <shaohua.li@intel.com>. 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 16:57 ` Randy.Dunlap @ 2006-02-03 18:46 ` Bartlomiej Zolnierkiewicz 0 siblings, 0 replies; 432+ messages in thread From: Bartlomiej Zolnierkiewicz @ 2006-02-03 18:46 UTC (permalink / raw) To: Randy.Dunlap Cc: Matthew Garrett, Andrew Morton, Lee Revell, nigel, torvalds, linux-kernel, Pavel Machek, Shaohua Li On 2/3/06, Randy.Dunlap <rdunlap@xenotime.net> wrote: > On Fri, 3 Feb 2006, Bartlomiej Zolnierkiewicz wrote: > > > On 2/3/06, Randy.Dunlap <rdunlap@xenotime.net> wrote: > > > On Fri, 3 Feb 2006, Bartlomiej Zolnierkiewicz wrote: > > > > > > > On 2/3/06, Matthew Garrett <mgarrett@chiark.greenend.org.uk> wrote: > > > > > Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> 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 <shaohua.li@intel.com>. 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 21:34 ` Lee Revell 2006-02-02 22:23 ` Andrew Morton @ 2006-02-02 22:54 ` Nigel Cunningham 1 sibling, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-02 22:54 UTC (permalink / raw) To: Lee Revell; +Cc: Andrew Morton, Pavel Machek, torvalds, linux-kernel [-- Attachment #1: Type: text/plain, Size: 965 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 21:27 ` Andrew Morton 2006-02-02 21:34 ` Lee Revell @ 2006-02-02 23:10 ` Rafael J. Wysocki 2006-02-02 23:18 ` Nigel Cunningham ` (3 subsequent siblings) 5 siblings, 0 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-02 23:10 UTC (permalink / raw) To: Andrew Morton; +Cc: Pavel Machek, nigel, torvalds, linux-kernel Hi, On Thursday 02 February 2006 22:27, Andrew Morton wrote: > Pavel Machek <pavel@ucw.cz> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 21:27 ` Andrew Morton 2006-02-02 21:34 ` Lee Revell 2006-02-02 23:10 ` Rafael J. Wysocki @ 2006-02-02 23:18 ` Nigel Cunningham 2006-02-03 1:00 ` [Suspend2-devel] " Bojan Smojver ` (2 more replies) 2006-02-03 11:21 ` [ 00/10] [Suspend2] Modules support Pavel Machek ` (2 subsequent siblings) 5 siblings, 3 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-02 23:18 UTC (permalink / raw) To: Andrew Morton, suspend2-devel; +Cc: Pavel Machek, torvalds, linux-kernel [-- Attachment #1: Type: text/plain, Size: 3772 bytes --] Hi Andrew et al. On Friday 03 February 2006 07:27, Andrew Morton wrote: > Pavel Machek <pavel@ucw.cz> 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 23:18 ` Nigel Cunningham @ 2006-02-03 1:00 ` Bojan Smojver 2006-02-03 1:18 ` Andrew Morton 2006-02-03 11:44 ` [ 00/10] [Suspend2] Modules support Pavel Machek [not found] ` <200602100007.10233.rjw@sisk.pl> 2 siblings, 1 reply; 432+ messages in thread From: Bojan Smojver @ 2006-02-03 1:00 UTC (permalink / raw) To: Nigel Cunningham Cc: Andrew Morton, suspend2-devel, torvalds, linux-kernel, Pavel Machek Quoting Nigel Cunningham <nigel@suspend2.net>: > 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 1:00 ` [Suspend2-devel] " Bojan Smojver @ 2006-02-03 1:18 ` Andrew Morton 2006-02-03 1:32 ` Nigel Cunningham 2006-02-03 1:42 ` Bojan Smojver 0 siblings, 2 replies; 432+ messages in thread From: Andrew Morton @ 2006-02-03 1:18 UTC (permalink / raw) To: Bojan Smojver; +Cc: nigel, suspend2-devel, torvalds, linux-kernel, pavel Bojan Smojver <bojan@rexursive.com> 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 1:18 ` Andrew Morton @ 2006-02-03 1:32 ` Nigel Cunningham 2006-02-03 1:42 ` Bojan Smojver 1 sibling, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-03 1:32 UTC (permalink / raw) To: Andrew Morton Cc: Bojan Smojver, suspend2-devel, torvalds, linux-kernel, pavel [-- Attachment #1: Type: text/plain, Size: 1123 bytes --] Hi again. On Friday 03 February 2006 11:18, Andrew Morton wrote: > Bojan Smojver <bojan@rexursive.com> 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 1:18 ` Andrew Morton 2006-02-03 1:32 ` Nigel Cunningham @ 2006-02-03 1:42 ` Bojan Smojver 2006-02-03 9:18 ` Rafael J. Wysocki 2006-02-03 11:49 ` Pavel Machek 1 sibling, 2 replies; 432+ messages in thread From: Bojan Smojver @ 2006-02-03 1:42 UTC (permalink / raw) To: Andrew Morton; +Cc: nigel, suspend2-devel, torvalds, linux-kernel, pavel Quoting Andrew Morton <akpm@osdl.org>: > 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 1:42 ` Bojan Smojver @ 2006-02-03 9:18 ` Rafael J. Wysocki [not found] ` <1138962557.18190.18.camel@coyote.rexursive.com> 2006-02-03 11:49 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-03 9:18 UTC (permalink / raw) To: Bojan Smojver Cc: Andrew Morton, nigel, suspend2-devel, torvalds, linux-kernel, pavel Hi, On Friday 03 February 2006 02:42, Bojan Smojver wrote: > Quoting Andrew Morton <akpm@osdl.org>: > > > 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
[parent not found: <1138962557.18190.18.camel@coyote.rexursive.com>]
[parent not found: <200602031254.37335.rjw@sisk.pl>]
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. [not found] ` <200602031254.37335.rjw@sisk.pl> @ 2006-02-03 23:53 ` Bojan Smojver 0 siblings, 0 replies; 432+ messages in thread From: Bojan Smojver @ 2006-02-03 23:53 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Suspend2 Devel List, linux-kernel On Fri, 2006-02-03 at 12:54 +0100, Rafael J. Wysocki wrote: > Well, unfortunately this is one of the problems I cannot solve. This should > really be reported to LKML as the ATI AGP driver problem or directly to the > developers of this particular driver. I can submit a bug report based on > the inormation from you, though. > > [swsusp uses whatever is in the drivers, so driver problems need to be > fixed by their developers.] This is exactly the point that I'm trying to make (and Nigel hinted something along these lines). These problems have obviously been solved in suspend2 (and I've got a machine to show it). Solutions are right there. But for some reason, we are back to the drawing board. I suggest you guys ask Nigel as to what he changed to make this work. I don't think he just put the code there at random. Look, I know I'm going to get blamed here for all kinds of things, from starting a flame war to being incompetent because I'm not a kernel hacker. That's cool. All I know is that somehow, somewhere, there are chunks of code in suspend2 that make things work. If I didn't know better, I would say it must be by magic :-) -- Bojan ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 1:42 ` Bojan Smojver 2006-02-03 9:18 ` Rafael J. Wysocki @ 2006-02-03 11:49 ` Pavel Machek 2006-02-03 23:43 ` Bojan Smojver 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-03 11:49 UTC (permalink / raw) To: Bojan Smojver Cc: Andrew Morton, nigel, suspend2-devel, torvalds, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 11:49 ` Pavel Machek @ 2006-02-03 23:43 ` Bojan Smojver 2006-02-03 23:55 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Bojan Smojver @ 2006-02-03 23:43 UTC (permalink / raw) To: Pavel Machek; +Cc: Andrew Morton, nigel, suspend2-devel, torvalds, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 23:43 ` Bojan Smojver @ 2006-02-03 23:55 ` Pavel Machek 2006-02-04 0:05 ` Bojan Smojver 2006-02-04 0:36 ` Olivier Galibert 0 siblings, 2 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-03 23:55 UTC (permalink / raw) To: Bojan Smojver Cc: Andrew Morton, nigel, suspend2-devel, torvalds, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 23:55 ` Pavel Machek @ 2006-02-04 0:05 ` Bojan Smojver [not found] ` <20060204005310.GG3291@elf.ucw.cz> 2006-02-04 0:36 ` Olivier Galibert 1 sibling, 1 reply; 432+ messages in thread From: Bojan Smojver @ 2006-02-04 0:05 UTC (permalink / raw) To: Pavel Machek; +Cc: Andrew Morton, nigel, suspend2-devel, torvalds, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
[parent not found: <20060204005310.GG3291@elf.ucw.cz>]
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. [not found] ` <20060204005310.GG3291@elf.ucw.cz> @ 2006-02-04 1:13 ` Bojan Smojver 2006-02-04 8:53 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Bojan Smojver @ 2006-02-04 1:13 UTC (permalink / raw) To: Pavel Machek; +Cc: Suspend2 Devel List, linux-kernel On Sat, 2006-02-04 at 01:53 +0100, Pavel Machek wrote: > No, it would not. Merging suspend2 now would mean usable suspend > support for you in 3 or so months, but would push uswsusp forward year > or more. >From my perspective, uswsusp is pie in the sky. I don't care if it gets pushed back or not. On the other hand suspend2 works - NOW. And it ain't just me. Do you really think all these folks that are using suspend2 have an urge to patch their notebook kernels just because they feel like it? But hey, you seem to be bent on not having it - and you seem to be the one making that calls, so the rest of us that just want to use the notebooks properly will have to patch until someone decides that having something that works is more important than being right all the time. It's OK, have it your way. -- Bojan ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 1:13 ` Bojan Smojver @ 2006-02-04 8:53 ` Pavel Machek 2006-02-04 10:08 ` Nigel Cunningham ` (2 more replies) 0 siblings, 3 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-04 8:53 UTC (permalink / raw) To: Bojan Smojver; +Cc: Suspend2 Devel List, linux-kernel This was personal email. It is pretty rude to post it to public lists. > But hey, you seem to be bent on not having it - and you seem to be the > one making that calls, so the rest of us that just want to use the > notebooks properly will have to patch until someone decides that having > something that works is more important than being right all the > time. In the end, it is important what is right, not what works. If you do not understand that -- bad for you. Pavel -- Thanks, Sharp! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 8:53 ` Pavel Machek @ 2006-02-04 10:08 ` Nigel Cunningham 2006-02-05 22:07 ` Pavel Machek 2006-02-04 13:59 ` Harald Arnesen 2006-02-05 2:59 ` Bojan Smojver 2 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-04 10:08 UTC (permalink / raw) To: suspend2-devel; +Cc: Pavel Machek, Bojan Smojver, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1757 bytes --] Hi. On Saturday 04 February 2006 18:53, Pavel Machek wrote: > This was personal email. It is pretty rude to post it to public lists. > > > But hey, you seem to be bent on not having it - and you seem to be the > > one making that calls, so the rest of us that just want to use the > > notebooks properly will have to patch until someone decides that > > having something that works is more important than being right all the > > time. > > In the end, it is important what is right, not what works. If you do > not understand that -- bad for you. True, but in something like putting code in the kernel vs in userspace, people apply different criteria in determining what is right. God hasn't written "You shall do suspend to disk in userspace" (and we'd probably rebel against Him anyway if He did :>), so we have to figure out what the best way is. Is userspace the 'right' solution? Well, yes, it does let you add features without adding to kernel code. But it also creates other problems. Putting it in kernel space has issues too - some things like userui are best left where they won't necessary take down the whole process if they don't work right. Personally, I think we're getting too polarised here. I've already accepted that there's a space for userspace code by merging (into Suspend2) code that puts the user interface there, along with management of storage. You agree that somethings, such as the atomic copy, simply can't be done in userspace. Without having looked seriously at the code yet, I'd be pretty sure that you're also leaving the calculation of what pages to store in the kernel. That just leaves how to store the image. Aren't we actually a lot closer than it has appeared? Nigel [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 10:08 ` Nigel Cunningham @ 2006-02-05 22:07 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-05 22:07 UTC (permalink / raw) To: Nigel Cunningham; +Cc: suspend2-devel, Bojan Smojver, linux-kernel Hi! > > This was personal email. It is pretty rude to post it to public lists. > > > > > But hey, you seem to be bent on not having it - and you seem to be the > > > one making that calls, so the rest of us that just want to use the > > > notebooks properly will have to patch until someone decides that > > > having something that works is more important than being right all the > > > time. > > > > In the end, it is important what is right, not what works. If you do > > not understand that -- bad for you. > > True, but in something like putting code in the kernel vs in userspace, > people apply different criteria in determining what is right. God hasn't > written "You shall do suspend to disk in userspace" (and we'd probably Would written notice from Linus be good enough? :-)))) > best way is. Is userspace the 'right' solution? Well, yes, it does let you > add features without adding to kernel code. But it also creates other > problems. Putting it in kernel space has issues too - some things like > userui are best left where they won't necessary take down the whole > process if they don't work right. Personally, I think we're getting too > polarised here. I've already accepted that there's a space for userspace > code by merging (into Suspend2) code that puts the user interface there, > along with management of storage. You agree that somethings, such as > the I did not know about storage management. > atomic copy, simply can't be done in userspace. Without having looked > seriously at the code yet, I'd be pretty sure that you're also leaving the > calculation of what pages to store in the kernel. That just leaves how to > store the image. Aren't we actually a lot closer than it has appeared? Well, perhaps we are. It should be possible to move suspend2 into userspace, and at that point we can share all the kernel-level code (and probably all the user-level code, too :-). Pavel -- Thanks, Sharp! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 8:53 ` Pavel Machek 2006-02-04 10:08 ` Nigel Cunningham @ 2006-02-04 13:59 ` Harald Arnesen 2006-02-05 3:06 ` Bojan Smojver 2006-02-05 2:59 ` Bojan Smojver 2 siblings, 1 reply; 432+ messages in thread From: Harald Arnesen @ 2006-02-04 13:59 UTC (permalink / raw) To: Pavel Machek; +Cc: Bojan Smojver, Suspend2 Devel List, linux-kernel Pavel Machek <pavel@ucw.cz> writes: > In the end, it is important what is right, not what works. If you do > not understand that -- bad for you. It what is right doesn't work, it's not much use, is it? -- Hilsen Harald. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 13:59 ` Harald Arnesen @ 2006-02-05 3:06 ` Bojan Smojver 0 siblings, 0 replies; 432+ messages in thread From: Bojan Smojver @ 2006-02-05 3:06 UTC (permalink / raw) To: Harald Arnesen; +Cc: Pavel Machek, Suspend2 Devel List, linux-kernel On Sat, 2006-02-04 at 14:59 +0100, Harald Arnesen wrote: > It what is right doesn't work, it's not much use, is it? Of course it is. Your *notebook* isn't of much use, but you can post on various lists claiming that you're right, which then compensates for your notebook not working. Life is a serious of trade-offs, isn't it? ;-) -- Bojan ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 8:53 ` Pavel Machek 2006-02-04 10:08 ` Nigel Cunningham 2006-02-04 13:59 ` Harald Arnesen @ 2006-02-05 2:59 ` Bojan Smojver 2 siblings, 0 replies; 432+ messages in thread From: Bojan Smojver @ 2006-02-05 2:59 UTC (permalink / raw) To: Pavel Machek; +Cc: Suspend2 Devel List, linux-kernel On Sat, 2006-02-04 at 09:53 +0100, Pavel Machek wrote: > In the end, it is important what is right, not what works. If you do > not understand that -- bad for you. Uh, oh, I'm finally getting it now... People buy notebooks to use them as doorstops. And, the important things is to be right - yep, it's all coming together now :-) -- Bojan ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 23:55 ` Pavel Machek 2006-02-04 0:05 ` Bojan Smojver @ 2006-02-04 0:36 ` Olivier Galibert 2006-02-04 0:49 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Olivier Galibert @ 2006-02-04 0:36 UTC (permalink / raw) To: Pavel Machek; +Cc: suspend2-devel, linux-kernel 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 0:36 ` Olivier Galibert @ 2006-02-04 0:49 ` Pavel Machek 2006-02-04 1:08 ` Olivier Galibert 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-04 0:49 UTC (permalink / raw) To: Olivier Galibert, suspend2-devel, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 0:49 ` Pavel Machek @ 2006-02-04 1:08 ` Olivier Galibert 2006-02-04 1:23 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Olivier Galibert @ 2006-02-04 1:08 UTC (permalink / raw) To: Pavel Machek; +Cc: suspend2-devel, linux-kernel 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 1:08 ` Olivier Galibert @ 2006-02-04 1:23 ` Pavel Machek 2006-02-04 2:18 ` Bojan Smojver 2006-02-04 13:51 ` chroot in swsusp userland interface (was: Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Rafael J. Wysocki 0 siblings, 2 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-04 1:23 UTC (permalink / raw) To: Olivier Galibert, suspend2-devel, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 1:23 ` Pavel Machek @ 2006-02-04 2:18 ` Bojan Smojver 2006-02-04 13:51 ` chroot in swsusp userland interface (was: Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Rafael J. Wysocki 1 sibling, 0 replies; 432+ messages in thread From: Bojan Smojver @ 2006-02-04 2:18 UTC (permalink / raw) To: Pavel Machek; +Cc: Olivier Galibert, suspend2-devel, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* chroot in swsusp userland interface (was: Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-04 1:23 ` Pavel Machek 2006-02-04 2:18 ` Bojan Smojver @ 2006-02-04 13:51 ` Rafael J. Wysocki 2006-02-04 19:21 ` Pavel Machek 2006-02-05 23:02 ` Nigel Cunningham 1 sibling, 2 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-04 13:51 UTC (permalink / raw) To: Pavel Machek; +Cc: Olivier Galibert, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: chroot in swsusp userland interface (was: Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-04 13:51 ` chroot in swsusp userland interface (was: Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Rafael J. Wysocki @ 2006-02-04 19:21 ` Pavel Machek 2006-02-04 19:57 ` Rafael J. Wysocki 2006-02-05 23:02 ` Nigel Cunningham 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-04 19:21 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Olivier Galibert, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: chroot in swsusp userland interface (was: Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-04 19:21 ` Pavel Machek @ 2006-02-04 19:57 ` Rafael J. Wysocki 2006-02-04 20:15 ` Pavel Machek 2006-02-06 9:05 ` Bernard Blackham 0 siblings, 2 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-04 19:57 UTC (permalink / raw) To: Pavel Machek; +Cc: Olivier Galibert, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: chroot in swsusp userland interface (was: Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-04 19:57 ` Rafael J. Wysocki @ 2006-02-04 20:15 ` Pavel Machek 2006-02-04 20:45 ` Rafael J. Wysocki 2006-02-06 9:05 ` Bernard Blackham 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-04 20:15 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Olivier Galibert, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: chroot in swsusp userland interface (was: Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-04 20:15 ` Pavel Machek @ 2006-02-04 20:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-04 20:45 UTC (permalink / raw) To: Pavel Machek; +Cc: Olivier Galibert, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: chroot in swsusp userland interface (was: Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-04 19:57 ` Rafael J. Wysocki 2006-02-04 20:15 ` Pavel Machek @ 2006-02-06 9:05 ` Bernard Blackham 1 sibling, 0 replies; 432+ messages in thread From: Bernard Blackham @ 2006-02-06 9:05 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Pavel Machek, Olivier Galibert, linux-kernel 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> ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: chroot in swsusp userland interface (was: Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-04 13:51 ` chroot in swsusp userland interface (was: Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Rafael J. Wysocki 2006-02-04 19:21 ` Pavel Machek @ 2006-02-05 23:02 ` Nigel Cunningham 2006-02-06 15:13 ` Rafael J. Wysocki 1 sibling, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-05 23:02 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Pavel Machek, Olivier Galibert, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2908 bytes --] 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: chroot in swsusp userland interface (was: Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-05 23:02 ` Nigel Cunningham @ 2006-02-06 15:13 ` Rafael J. Wysocki 2006-02-08 23:51 ` Nigel Cunningham 0 siblings, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-06 15:13 UTC (permalink / raw) To: Nigel Cunningham Cc: Pavel Machek, Olivier Galibert, linux-kernel, Bernard Blackham 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 suspend-devel@lists.sourceforge.net 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: chroot in swsusp userland interface (was: Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 15:13 ` Rafael J. Wysocki @ 2006-02-08 23:51 ` Nigel Cunningham 0 siblings, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-08 23:51 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Pavel Machek, Olivier Galibert, linux-kernel, Bernard Blackham [-- Attachment #1: Type: text/plain, Size: 1106 bytes --] 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 suspend-devel@lists.sourceforge.net 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 23:18 ` Nigel Cunningham 2006-02-03 1:00 ` [Suspend2-devel] " Bojan Smojver @ 2006-02-03 11:44 ` Pavel Machek 2006-02-03 23:42 ` [Suspend2-devel] " Bojan Smojver 2006-02-04 1:20 ` Nigel Cunningham [not found] ` <200602100007.10233.rjw@sisk.pl> 2 siblings, 2 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-03 11:44 UTC (permalink / raw) To: Nigel Cunningham; +Cc: suspend2-devel, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 11:44 ` [ 00/10] [Suspend2] Modules support Pavel Machek @ 2006-02-03 23:42 ` Bojan Smojver 2006-02-04 1:20 ` Nigel Cunningham 1 sibling, 0 replies; 432+ messages in thread From: Bojan Smojver @ 2006-02-03 23:42 UTC (permalink / raw) To: Pavel Machek; +Cc: Nigel Cunningham, linux-kernel, suspend2-devel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-03 11:44 ` [ 00/10] [Suspend2] Modules support Pavel Machek 2006-02-03 23:42 ` [Suspend2-devel] " Bojan Smojver @ 2006-02-04 1:20 ` Nigel Cunningham 2006-02-04 9:01 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-04 1:20 UTC (permalink / raw) To: Pavel Machek; +Cc: suspend2-devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 565 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 1:20 ` Nigel Cunningham @ 2006-02-04 9:01 ` Pavel Machek 2006-02-04 9:54 ` Nigel Cunningham 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-04 9:01 UTC (permalink / raw) To: Nigel Cunningham; +Cc: suspend2-devel, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 9:01 ` Pavel Machek @ 2006-02-04 9:54 ` Nigel Cunningham 2006-02-04 10:58 ` Rafael J. Wysocki 2006-02-04 19:29 ` Pavel Machek 0 siblings, 2 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-04 9:54 UTC (permalink / raw) To: Pavel Machek; +Cc: suspend2-devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1636 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 9:54 ` Nigel Cunningham @ 2006-02-04 10:58 ` Rafael J. Wysocki 2006-02-04 11:08 ` Nigel Cunningham 2006-02-04 19:29 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-04 10:58 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Pavel Machek, suspend2-devel, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 10:58 ` Rafael J. Wysocki @ 2006-02-04 11:08 ` Nigel Cunningham 2006-02-04 11:38 ` Rafael J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-04 11:08 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Pavel Machek, suspend2-devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 3330 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 11:08 ` Nigel Cunningham @ 2006-02-04 11:38 ` Rafael J. Wysocki 2006-02-04 11:41 ` Nigel Cunningham 2006-02-04 19:10 ` Pavel Machek 0 siblings, 2 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-04 11:38 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Pavel Machek, suspend2-devel, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 11:38 ` Rafael J. Wysocki @ 2006-02-04 11:41 ` Nigel Cunningham 2006-02-04 13:09 ` Rafael J. Wysocki 2006-02-04 17:18 ` Rafael J. Wysocki 2006-02-04 19:10 ` Pavel Machek 1 sibling, 2 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-04 11:41 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Pavel Machek, suspend2-devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2901 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 11:41 ` Nigel Cunningham @ 2006-02-04 13:09 ` Rafael J. Wysocki 2006-02-04 17:18 ` Rafael J. Wysocki 1 sibling, 0 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-04 13:09 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Pavel Machek, suspend2-devel, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 11:41 ` Nigel Cunningham 2006-02-04 13:09 ` Rafael J. Wysocki @ 2006-02-04 17:18 ` Rafael J. Wysocki 2006-02-05 23:43 ` [Suspend2-devel] " Nigel Cunningham 1 sibling, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-04 17:18 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Pavel Machek, suspend2-devel, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 17:18 ` Rafael J. Wysocki @ 2006-02-05 23:43 ` Nigel Cunningham 2006-02-05 23:56 ` Rafael J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-05 23:43 UTC (permalink / raw) To: suspend2-devel; +Cc: Rafael J. Wysocki, Pavel Machek, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2715 bytes --] 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 > Suspend2-devel@lists.suspend2.net > 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-05 23:43 ` [Suspend2-devel] " Nigel Cunningham @ 2006-02-05 23:56 ` Rafael J. Wysocki 2006-02-06 21:07 ` Jim Crilly 0 siblings, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-05 23:56 UTC (permalink / raw) To: Nigel Cunningham; +Cc: suspend2-devel, Pavel Machek, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-05 23:56 ` Rafael J. Wysocki @ 2006-02-06 21:07 ` Jim Crilly 2006-02-07 0:16 ` Nigel Cunningham 0 siblings, 1 reply; 432+ messages in thread From: Jim Crilly @ 2006-02-06 21:07 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Nigel Cunningham, suspend2-devel, Pavel Machek, linux-kernel 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-06 21:07 ` Jim Crilly @ 2006-02-07 0:16 ` Nigel Cunningham 2006-02-07 15:16 ` Rafael J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-07 0:16 UTC (permalink / raw) To: suspend2-devel; +Cc: Jim Crilly, Rafael J. Wysocki, Pavel Machek, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2082 bytes --] 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 > Suspend2-devel@lists.suspend2.net > 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-07 0:16 ` Nigel Cunningham @ 2006-02-07 15:16 ` Rafael J. Wysocki 0 siblings, 0 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-07 15:16 UTC (permalink / raw) To: Nigel Cunningham; +Cc: suspend2-devel, Jim Crilly, Pavel Machek, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 11:38 ` Rafael J. Wysocki 2006-02-04 11:41 ` Nigel Cunningham @ 2006-02-04 19:10 ` Pavel Machek 2006-02-05 23:44 ` [Suspend2-devel] " Nigel Cunningham 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-04 19:10 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Nigel Cunningham, suspend2-devel, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 19:10 ` Pavel Machek @ 2006-02-05 23:44 ` Nigel Cunningham 2006-02-06 10:13 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-05 23:44 UTC (permalink / raw) To: suspend2-devel; +Cc: Pavel Machek, Rafael J. Wysocki, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1198 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support. 2006-02-05 23:44 ` [Suspend2-devel] " Nigel Cunningham @ 2006-02-06 10:13 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-06 10:13 UTC (permalink / raw) To: Nigel Cunningham; +Cc: suspend2-devel, Rafael J. Wysocki, linux-kernel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 9:54 ` Nigel Cunningham 2006-02-04 10:58 ` Rafael J. Wysocki @ 2006-02-04 19:29 ` Pavel Machek 2006-02-06 4:02 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Nigel Cunningham 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-04 19:29 UTC (permalink / raw) To: Nigel Cunningham; +Cc: suspend2-devel, linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-04 19:29 ` Pavel Machek @ 2006-02-06 4:02 ` Nigel Cunningham 2006-02-06 4:34 ` Lee Revell 2006-02-06 10:59 ` Pavel Machek 0 siblings, 2 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-06 4:02 UTC (permalink / raw) To: Pavel Machek; +Cc: Rafael Wysocki, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 4:02 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Nigel Cunningham @ 2006-02-06 4:34 ` Lee Revell 2006-02-06 5:43 ` Nigel Cunningham 2006-02-06 10:59 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Lee Revell @ 2006-02-06 4:34 UTC (permalink / raw) To: Nigel Cunningham Cc: Pavel Machek, Rafael Wysocki, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 4:34 ` Lee Revell @ 2006-02-06 5:43 ` Nigel Cunningham 2006-02-06 18:48 ` Lee Revell 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-06 5:43 UTC (permalink / raw) To: Lee Revell Cc: Pavel Machek, Rafael Wysocki, linux-kernel, Suspend2 Devel List [-- Attachment #1: Type: text/plain, Size: 779 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 5:43 ` Nigel Cunningham @ 2006-02-06 18:48 ` Lee Revell 2006-02-06 20:25 ` Nigel Cunningham 0 siblings, 1 reply; 432+ messages in thread From: Lee Revell @ 2006-02-06 18:48 UTC (permalink / raw) To: Nigel Cunningham Cc: Pavel Machek, Rafael Wysocki, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 18:48 ` Lee Revell @ 2006-02-06 20:25 ` Nigel Cunningham 2006-02-06 23:51 ` Rafael J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-06 20:25 UTC (permalink / raw) To: suspend2-devel; +Cc: Lee Revell, Rafael Wysocki, linux-kernel, Pavel Machek [-- Attachment #1: Type: text/plain, Size: 1940 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 20:25 ` Nigel Cunningham @ 2006-02-06 23:51 ` Rafael J. Wysocki 2006-02-06 23:57 ` Nigel Cunningham ` (2 more replies) 0 siblings, 3 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-06 23:51 UTC (permalink / raw) To: Nigel Cunningham; +Cc: suspend2-devel, Lee Revell, linux-kernel, Pavel Machek 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 23:51 ` Rafael J. Wysocki @ 2006-02-06 23:57 ` Nigel Cunningham 2006-02-07 0:29 ` Pavel Machek 2006-02-07 0:31 ` Bojan Smojver 2006-02-07 0:37 ` Jim Crilly 2 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-06 23:57 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: suspend2-devel, Lee Revell, linux-kernel, Pavel Machek [-- Attachment #1: Type: text/plain, Size: 3354 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 23:57 ` Nigel Cunningham @ 2006-02-07 0:29 ` Pavel Machek 2006-02-07 0:43 ` Nigel Cunningham 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-07 0:29 UTC (permalink / raw) To: Nigel Cunningham Cc: Rafael J. Wysocki, suspend2-devel, Lee Revell, linux-kernel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 0:29 ` Pavel Machek @ 2006-02-07 0:43 ` Nigel Cunningham 0 siblings, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-07 0:43 UTC (permalink / raw) To: Pavel Machek; +Cc: Rafael J. Wysocki, suspend2-devel, Lee Revell, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2206 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 23:51 ` Rafael J. Wysocki 2006-02-06 23:57 ` Nigel Cunningham @ 2006-02-07 0:31 ` Bojan Smojver 2006-02-07 0:44 ` Pavel Machek 2006-02-07 0:37 ` Jim Crilly 2 siblings, 1 reply; 432+ messages in thread From: Bojan Smojver @ 2006-02-07 0:31 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Nigel Cunningham, Pavel Machek, Lee Revell, linux-kernel, suspend2-devel Quoting "Rafael J. Wysocki" <rjw@sisk.pl>: > 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 0:31 ` Bojan Smojver @ 2006-02-07 0:44 ` Pavel Machek 2006-02-07 1:05 ` Nigel Cunningham 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-07 0:44 UTC (permalink / raw) To: Bojan Smojver Cc: Rafael J. Wysocki, Nigel Cunningham, Lee Revell, linux-kernel, suspend2-devel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 0:44 ` Pavel Machek @ 2006-02-07 1:05 ` Nigel Cunningham 2006-02-07 2:20 ` Bojan Smojver ` (2 more replies) 0 siblings, 3 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-07 1:05 UTC (permalink / raw) To: Pavel Machek Cc: Bojan Smojver, Rafael J. Wysocki, Lee Revell, linux-kernel, suspend2-devel [-- Attachment #1: Type: text/plain, Size: 1616 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 1:05 ` Nigel Cunningham @ 2006-02-07 2:20 ` Bojan Smojver 2006-02-07 9:23 ` Pavel Machek 2006-02-07 15:09 ` Rafael J. Wysocki 2 siblings, 0 replies; 432+ messages in thread From: Bojan Smojver @ 2006-02-07 2:20 UTC (permalink / raw) To: Pavel Machek; +Cc: linux-kernel, suspend2-devel Quoting Pavel Machek <pavel@ucw.cz>: > 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 1:05 ` Nigel Cunningham 2006-02-07 2:20 ` Bojan Smojver @ 2006-02-07 9:23 ` Pavel Machek 2006-02-07 10:06 ` Nigel Cunningham 2006-02-07 15:09 ` Rafael J. Wysocki 2 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-07 9:23 UTC (permalink / raw) To: Nigel Cunningham Cc: Bojan Smojver, Rafael J. Wysocki, Lee Revell, linux-kernel, suspend2-devel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 9:23 ` Pavel Machek @ 2006-02-07 10:06 ` Nigel Cunningham 2006-02-07 23:03 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-07 10:06 UTC (permalink / raw) To: Pavel Machek Cc: Bojan Smojver, Rafael J. Wysocki, Lee Revell, linux-kernel, suspend2-devel [-- Attachment #1: Type: text/plain, Size: 1834 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 10:06 ` Nigel Cunningham @ 2006-02-07 23:03 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-07 23:03 UTC (permalink / raw) To: Nigel Cunningham Cc: Bojan Smojver, Rafael J. Wysocki, Lee Revell, linux-kernel, suspend2-devel > > 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 1:05 ` Nigel Cunningham 2006-02-07 2:20 ` Bojan Smojver 2006-02-07 9:23 ` Pavel Machek @ 2006-02-07 15:09 ` Rafael J. Wysocki 2006-02-07 22:13 ` Nigel Cunningham 2 siblings, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-07 15:09 UTC (permalink / raw) To: Nigel Cunningham Cc: Pavel Machek, Bojan Smojver, Lee Revell, linux-kernel, suspend2-devel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 15:09 ` Rafael J. Wysocki @ 2006-02-07 22:13 ` Nigel Cunningham 2006-02-07 23:05 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-07 22:13 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Pavel Machek, Bojan Smojver, Lee Revell, linux-kernel, suspend2-devel [-- Attachment #1: Type: text/plain, Size: 2770 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 22:13 ` Nigel Cunningham @ 2006-02-07 23:05 ` Pavel Machek 2006-02-07 23:13 ` Nigel Cunningham 2006-02-07 23:17 ` Nigel Cunningham 0 siblings, 2 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-07 23:05 UTC (permalink / raw) To: Nigel Cunningham Cc: Rafael J. Wysocki, Bojan Smojver, Lee Revell, linux-kernel, suspend2-devel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 23:05 ` Pavel Machek @ 2006-02-07 23:13 ` Nigel Cunningham 2006-02-07 23:17 ` Nigel Cunningham 1 sibling, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-07 23:13 UTC (permalink / raw) To: Pavel Machek Cc: Rafael J. Wysocki, Bojan Smojver, Lee Revell, linux-kernel, suspend2-devel [-- Attachment #1: Type: text/plain, Size: 1872 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 23:05 ` Pavel Machek 2006-02-07 23:13 ` Nigel Cunningham @ 2006-02-07 23:17 ` Nigel Cunningham 2006-02-07 23:36 ` Pavel Machek 2006-02-07 23:50 ` Rafael J. Wysocki 1 sibling, 2 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-07 23:17 UTC (permalink / raw) To: Pavel Machek Cc: Rafael J. Wysocki, Bojan Smojver, Lee Revell, linux-kernel, suspend2-devel [-- Attachment #1: Type: text/plain, Size: 2137 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 23:17 ` Nigel Cunningham @ 2006-02-07 23:36 ` Pavel Machek 2006-02-07 23:50 ` Rafael J. Wysocki 1 sibling, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-07 23:36 UTC (permalink / raw) To: Nigel Cunningham Cc: Rafael J. Wysocki, Bojan Smojver, Lee Revell, linux-kernel, suspend2-devel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 23:17 ` Nigel Cunningham 2006-02-07 23:36 ` Pavel Machek @ 2006-02-07 23:50 ` Rafael J. Wysocki 1 sibling, 0 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-07 23:50 UTC (permalink / raw) To: Nigel Cunningham Cc: Pavel Machek, Bojan Smojver, Lee Revell, linux-kernel, suspend2-devel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 23:51 ` Rafael J. Wysocki 2006-02-06 23:57 ` Nigel Cunningham 2006-02-07 0:31 ` Bojan Smojver @ 2006-02-07 0:37 ` Jim Crilly 2006-02-07 0:46 ` Pavel Machek 2 siblings, 1 reply; 432+ messages in thread From: Jim Crilly @ 2006-02-07 0:37 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Nigel Cunningham, suspend2-devel, Lee Revell, linux-kernel, Pavel Machek 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 0:37 ` Jim Crilly @ 2006-02-07 0:46 ` Pavel Machek 2006-02-07 0:59 ` Jim Crilly 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-07 0:46 UTC (permalink / raw) To: Rafael J. Wysocki, Nigel Cunningham, suspend2-devel, Lee Revell, linux-kernel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 0:46 ` Pavel Machek @ 2006-02-07 0:59 ` Jim Crilly 2006-02-07 1:19 ` Lee Revell 0 siblings, 1 reply; 432+ messages in thread From: Jim Crilly @ 2006-02-07 0:59 UTC (permalink / raw) To: Pavel Machek Cc: Rafael J. Wysocki, Nigel Cunningham, suspend2-devel, Lee Revell, linux-kernel 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 0:59 ` Jim Crilly @ 2006-02-07 1:19 ` Lee Revell 2006-02-07 3:01 ` Jim Crilly 0 siblings, 1 reply; 432+ messages in thread From: Lee Revell @ 2006-02-07 1:19 UTC (permalink / raw) To: Jim Crilly Cc: Pavel Machek, Rafael J. Wysocki, Nigel Cunningham, suspend2-devel, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 1:19 ` Lee Revell @ 2006-02-07 3:01 ` Jim Crilly 2006-02-07 3:03 ` Nigel Cunningham ` (2 more replies) 0 siblings, 3 replies; 432+ messages in thread From: Jim Crilly @ 2006-02-07 3:01 UTC (permalink / raw) To: Lee Revell Cc: Pavel Machek, Rafael J. Wysocki, Nigel Cunningham, suspend2-devel, linux-kernel 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 3:01 ` Jim Crilly @ 2006-02-07 3:03 ` Nigel Cunningham 2006-02-07 3:13 ` Lee Revell 2006-02-07 3:17 ` Lee Revell 2 siblings, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-07 3:03 UTC (permalink / raw) To: Jim Crilly Cc: Lee Revell, Pavel Machek, Rafael J. Wysocki, suspend2-devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2204 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 3:01 ` Jim Crilly 2006-02-07 3:03 ` Nigel Cunningham @ 2006-02-07 3:13 ` Lee Revell 2006-02-07 3:26 ` Nigel Cunningham 2006-02-07 9:37 ` Pavel Machek 2006-02-07 3:17 ` Lee Revell 2 siblings, 2 replies; 432+ messages in thread From: Lee Revell @ 2006-02-07 3:13 UTC (permalink / raw) To: Jim Crilly Cc: Pavel Machek, Rafael J. Wysocki, Nigel Cunningham, suspend2-devel, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 3:13 ` Lee Revell @ 2006-02-07 3:26 ` Nigel Cunningham 2006-02-07 9:37 ` Pavel Machek 1 sibling, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-07 3:26 UTC (permalink / raw) To: Lee Revell Cc: Jim Crilly, Pavel Machek, Rafael J. Wysocki, suspend2-devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1927 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 3:13 ` Lee Revell 2006-02-07 3:26 ` Nigel Cunningham @ 2006-02-07 9:37 ` Pavel Machek 2006-02-07 9:40 ` Nigel Cunningham 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-07 9:37 UTC (permalink / raw) To: Lee Revell Cc: Jim Crilly, Rafael J. Wysocki, Nigel Cunningham, suspend2-devel, linux-kernel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 9:37 ` Pavel Machek @ 2006-02-07 9:40 ` Nigel Cunningham 2006-02-07 23:02 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-07 9:40 UTC (permalink / raw) To: Pavel Machek Cc: Lee Revell, Jim Crilly, Rafael J. Wysocki, suspend2-devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2065 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 9:40 ` Nigel Cunningham @ 2006-02-07 23:02 ` Pavel Machek 2006-02-07 23:11 ` Nigel Cunningham ` (3 more replies) 0 siblings, 4 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-07 23:02 UTC (permalink / raw) To: Nigel Cunningham Cc: Lee Revell, Jim Crilly, Rafael J. Wysocki, suspend2-devel, linux-kernel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 23:02 ` Pavel Machek @ 2006-02-07 23:11 ` Nigel Cunningham 2006-02-08 6:59 ` Rafael J. Wysocki 2006-02-07 23:27 ` Rafael J. Wysocki ` (2 subsequent siblings) 3 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-07 23:11 UTC (permalink / raw) To: Pavel Machek Cc: Lee Revell, Jim Crilly, Rafael J. Wysocki, suspend2-devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2030 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 23:11 ` Nigel Cunningham @ 2006-02-08 6:59 ` Rafael J. Wysocki 2006-02-08 7:33 ` Nigel Cunningham 0 siblings, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-08 6:59 UTC (permalink / raw) To: Nigel Cunningham Cc: Pavel Machek, Lee Revell, Jim Crilly, suspend2-devel, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-08 6:59 ` Rafael J. Wysocki @ 2006-02-08 7:33 ` Nigel Cunningham 2006-02-08 8:15 ` Pavel Machek 2006-02-08 10:03 ` Rafael J. Wysocki 0 siblings, 2 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-08 7:33 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Pavel Machek, Lee Revell, Jim Crilly, suspend2-devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 4419 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-08 7:33 ` Nigel Cunningham @ 2006-02-08 8:15 ` Pavel Machek 2006-02-08 10:03 ` Rafael J. Wysocki 1 sibling, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-08 8:15 UTC (permalink / raw) To: Nigel Cunningham Cc: Rafael J. Wysocki, Lee Revell, Jim Crilly, suspend2-devel, linux-kernel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-08 7:33 ` Nigel Cunningham 2006-02-08 8:15 ` Pavel Machek @ 2006-02-08 10:03 ` Rafael J. Wysocki 2006-02-08 12:08 ` Nigel Cunningham 1 sibling, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-08 10:03 UTC (permalink / raw) To: Nigel Cunningham Cc: Pavel Machek, Lee Revell, Jim Crilly, suspend2-devel, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-08 10:03 ` Rafael J. Wysocki @ 2006-02-08 12:08 ` Nigel Cunningham 2006-02-09 0:06 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-08 12:08 UTC (permalink / raw) To: suspend2-devel; +Cc: Rafael J. Wysocki, Lee Revell, Pavel Machek, linux-kernel [-- Attachment #1: Type: text/plain, Size: 936 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-08 12:08 ` Nigel Cunningham @ 2006-02-09 0:06 ` Pavel Machek 2006-02-09 2:45 ` Nigel Cunningham 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-09 0:06 UTC (permalink / raw) To: Nigel Cunningham Cc: suspend2-devel, Rafael J. Wysocki, Lee Revell, linux-kernel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-09 0:06 ` Pavel Machek @ 2006-02-09 2:45 ` Nigel Cunningham 2006-02-09 9:25 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-09 2:45 UTC (permalink / raw) To: Pavel Machek; +Cc: suspend2-devel, Rafael J. Wysocki, Lee Revell, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2216 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-09 2:45 ` Nigel Cunningham @ 2006-02-09 9:25 ` Pavel Machek 2006-02-09 9:26 ` Nigel Cunningham 2006-02-09 13:22 ` Rafael J. Wysocki 0 siblings, 2 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-09 9:25 UTC (permalink / raw) To: Nigel Cunningham Cc: suspend2-devel, Rafael J. Wysocki, Lee Revell, linux-kernel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-09 9:25 ` Pavel Machek @ 2006-02-09 9:26 ` Nigel Cunningham 2006-02-09 23:24 ` Pavel Machek 2006-02-09 13:22 ` Rafael J. Wysocki 1 sibling, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-09 9:26 UTC (permalink / raw) To: Pavel Machek; +Cc: suspend2-devel, Rafael J. Wysocki, Lee Revell, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1970 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-09 9:26 ` Nigel Cunningham @ 2006-02-09 23:24 ` Pavel Machek 2006-02-11 0:16 ` Sebastian Kügler 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-09 23:24 UTC (permalink / raw) To: Nigel Cunningham Cc: suspend2-devel, Rafael J. Wysocki, Lee Revell, linux-kernel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-09 23:24 ` Pavel Machek @ 2006-02-11 0:16 ` Sebastian Kügler 2006-02-11 1:12 ` Pavel Machek 2006-02-11 10:41 ` Matthias Hensler 0 siblings, 2 replies; 432+ messages in thread From: Sebastian Kügler @ 2006-02-11 0:16 UTC (permalink / raw) To: suspend2-devel Cc: Pavel Machek, Nigel Cunningham, Rafael J. Wysocki, Lee Revell, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2421 bytes --] 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, b-swweb@blackham.com.au [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. [-- Attachment #2: Type: application/pgp-signature, Size: 481 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-11 0:16 ` Sebastian Kügler @ 2006-02-11 1:12 ` Pavel Machek 2006-02-11 10:41 ` Matthias Hensler 1 sibling, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-11 1:12 UTC (permalink / raw) To: Sebastian Kügler Cc: suspend2-devel, Nigel Cunningham, Rafael J. Wysocki, Lee Revell, linux-kernel 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, b-swweb@blackham.com.au > [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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-11 0:16 ` Sebastian Kügler 2006-02-11 1:12 ` Pavel Machek @ 2006-02-11 10:41 ` Matthias Hensler 2006-02-18 14:26 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Matthias Hensler @ 2006-02-11 10:41 UTC (permalink / raw) To: Sebastian Kügler Cc: suspend2-devel, Nigel Cunningham, Rafael J. Wysocki, Lee Revell, linux-kernel, Pavel Machek [-- Attachment #1: Type: text/plain, Size: 4743 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 307 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-11 10:41 ` Matthias Hensler @ 2006-02-18 14:26 ` Pavel Machek 2006-02-19 21:09 ` Nigel Cunningham 2006-02-20 9:39 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Matthias Hensler 0 siblings, 2 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-18 14:26 UTC (permalink / raw) To: Matthias Hensler; +Cc: Sebastian Kgler, kernel list, nigel, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-18 14:26 ` Pavel Machek @ 2006-02-19 21:09 ` Nigel Cunningham 2006-02-19 21:29 ` Pavel Machek 2006-02-19 23:42 ` suspend2 review [was Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)] Pavel Machek 2006-02-20 9:39 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Matthias Hensler 1 sibling, 2 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-19 21:09 UTC (permalink / raw) To: Pavel Machek; +Cc: Matthias Hensler, Sebastian Kgler, kernel list, rjw [-- Attachment #1: Type: text/plain, Size: 4928 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-19 21:09 ` Nigel Cunningham @ 2006-02-19 21:29 ` Pavel Machek 2006-02-20 0:24 ` Nigel Cunningham 2006-02-20 9:43 ` Matthias Hensler 2006-02-19 23:42 ` suspend2 review [was Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)] Pavel Machek 1 sibling, 2 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-19 21:29 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Matthias Hensler, Sebastian Kgler, kernel list, rjw 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-19 21:29 ` Pavel Machek @ 2006-02-20 0:24 ` Nigel Cunningham 2006-02-20 0:53 ` Pavel Machek 2006-02-20 9:43 ` Matthias Hensler 1 sibling, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-20 0:24 UTC (permalink / raw) To: Pavel Machek; +Cc: Matthias Hensler, Sebastian Kgler, kernel list, rjw [-- Attachment #1: Type: text/plain, Size: 3770 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 0:24 ` Nigel Cunningham @ 2006-02-20 0:53 ` Pavel Machek 2006-02-20 2:50 ` Nigel Cunningham 2006-02-20 9:47 ` Matthias Hensler 0 siblings, 2 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 0:53 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Matthias Hensler, Sebastian Kgler, kernel list, rjw 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 0:53 ` Pavel Machek @ 2006-02-20 2:50 ` Nigel Cunningham 2006-02-20 12:53 ` Pavel Machek 2006-02-20 9:47 ` Matthias Hensler 1 sibling, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-20 2:50 UTC (permalink / raw) To: Pavel Machek; +Cc: Matthias Hensler, Sebastian Kgler, kernel list, rjw [-- Attachment #1: Type: text/plain, Size: 3901 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 2:50 ` Nigel Cunningham @ 2006-02-20 12:53 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 12:53 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Matthias Hensler, Sebastian Kgler, kernel list, rjw 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 0:53 ` Pavel Machek 2006-02-20 2:50 ` Nigel Cunningham @ 2006-02-20 9:47 ` Matthias Hensler 2006-02-20 10:56 ` Pavel Machek 2006-02-21 4:32 ` Andy Lutomirski 1 sibling, 2 replies; 432+ messages in thread From: Matthias Hensler @ 2006-02-20 9:47 UTC (permalink / raw) To: Pavel Machek; +Cc: Nigel Cunningham, Sebastian Kgler, kernel list, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 9:47 ` Matthias Hensler @ 2006-02-20 10:56 ` Pavel Machek 2006-02-20 11:04 ` Nigel Cunningham 2006-02-20 11:17 ` Matthias Hensler 2006-02-21 4:32 ` Andy Lutomirski 1 sibling, 2 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 10:56 UTC (permalink / raw) To: Matthias Hensler; +Cc: Nigel Cunningham, Sebastian Kgler, kernel list, rjw 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:56 ` Pavel Machek @ 2006-02-20 11:04 ` Nigel Cunningham 2006-02-20 13:20 ` Pavel Machek 2006-02-20 11:17 ` Matthias Hensler 1 sibling, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-20 11:04 UTC (permalink / raw) To: Pavel Machek; +Cc: Matthias Hensler, Sebastian Kgler, kernel list, rjw [-- Attachment #1: Type: text/plain, Size: 1119 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 11:04 ` Nigel Cunningham @ 2006-02-20 13:20 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 13:20 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Matthias Hensler, Sebastian Kgler, kernel list, rjw > 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:56 ` Pavel Machek 2006-02-20 11:04 ` Nigel Cunningham @ 2006-02-20 11:17 ` Matthias Hensler 2006-02-20 11:20 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Matthias Hensler @ 2006-02-20 11:17 UTC (permalink / raw) To: Pavel Machek; +Cc: Nigel Cunningham, Sebastian Kgler, kernel list, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 11:17 ` Matthias Hensler @ 2006-02-20 11:20 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 11:20 UTC (permalink / raw) To: Matthias Hensler; +Cc: Nigel Cunningham, Sebastian Kgler, kernel list, rjw 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 9:47 ` Matthias Hensler 2006-02-20 10:56 ` Pavel Machek @ 2006-02-21 4:32 ` Andy Lutomirski 2006-02-21 4:45 ` Nigel Cunningham 2006-02-21 11:33 ` Pavel Machek 1 sibling, 2 replies; 432+ messages in thread From: Andy Lutomirski @ 2006-02-21 4:32 UTC (permalink / raw) To: Matthias Hensler, kernel list Cc: Nigel Cunningham, Sebastian Kgler, rjw, pavel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-21 4:32 ` Andy Lutomirski @ 2006-02-21 4:45 ` Nigel Cunningham 2006-02-21 11:39 ` Pavel Machek 2006-02-21 11:33 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-21 4:45 UTC (permalink / raw) To: Andy Lutomirski Cc: Matthias Hensler, kernel list, Sebastian Kgler, rjw, pavel [-- Attachment #1: Type: text/plain, Size: 3897 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-21 4:45 ` Nigel Cunningham @ 2006-02-21 11:39 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-21 11:39 UTC (permalink / raw) To: Nigel Cunningham Cc: Andy Lutomirski, Matthias Hensler, kernel list, Sebastian Kgler, rjw 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-21 4:32 ` Andy Lutomirski 2006-02-21 4:45 ` Nigel Cunningham @ 2006-02-21 11:33 ` Pavel Machek 2006-02-21 20:36 ` Rafael J. Wysocki 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-21 11:33 UTC (permalink / raw) To: Andy Lutomirski Cc: Matthias Hensler, kernel list, Nigel Cunningham, Sebastian Kgler, rjw 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-21 11:33 ` Pavel Machek @ 2006-02-21 20:36 ` Rafael J. Wysocki 0 siblings, 0 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-21 20:36 UTC (permalink / raw) To: Pavel Machek Cc: Andy Lutomirski, Matthias Hensler, kernel list, Nigel Cunningham, Sebastian Kgler 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-19 21:29 ` Pavel Machek 2006-02-20 0:24 ` Nigel Cunningham @ 2006-02-20 9:43 ` Matthias Hensler 2006-02-20 10:36 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Matthias Hensler @ 2006-02-20 9:43 UTC (permalink / raw) To: Pavel Machek; +Cc: Nigel Cunningham, Sebastian Kgler, kernel list, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 9:43 ` Matthias Hensler @ 2006-02-20 10:36 ` Pavel Machek 2006-02-20 10:50 ` Matthias Hensler 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-20 10:36 UTC (permalink / raw) To: Matthias Hensler; +Cc: Nigel Cunningham, Sebastian Kgler, kernel list, rjw 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:36 ` Pavel Machek @ 2006-02-20 10:50 ` Matthias Hensler 2006-02-20 10:54 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Matthias Hensler @ 2006-02-20 10:50 UTC (permalink / raw) To: Pavel Machek; +Cc: Nigel Cunningham, Sebastian Kgler, kernel list, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:50 ` Matthias Hensler @ 2006-02-20 10:54 ` Pavel Machek 2006-02-20 11:17 ` Matthias Hensler 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-20 10:54 UTC (permalink / raw) To: Matthias Hensler; +Cc: Nigel Cunningham, Sebastian Kgler, kernel list, rjw 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:54 ` Pavel Machek @ 2006-02-20 11:17 ` Matthias Hensler 2006-02-20 13:08 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Matthias Hensler @ 2006-02-20 11:17 UTC (permalink / raw) To: Pavel Machek; +Cc: Nigel Cunningham, Sebastian Kgler, kernel list, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 11:17 ` Matthias Hensler @ 2006-02-20 13:08 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 13:08 UTC (permalink / raw) To: Matthias Hensler; +Cc: Nigel Cunningham, Sebastian Kgler, kernel list, rjw 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* suspend2 review [was Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)] 2006-02-19 21:09 ` Nigel Cunningham 2006-02-19 21:29 ` Pavel Machek @ 2006-02-19 23:42 ` Pavel Machek [not found] ` <200602191935.36844.dtor_core@ameritech.net> 2006-02-20 2:10 ` Nigel Cunningham 1 sibling, 2 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-19 23:42 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Matthias Hensler, Sebastian Kgler, kernel list, rjw 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 <nigel@suspend2.net> + * Based on code + * Copyright 2001-2002 Pavel Machek <pavel@suse.cz> + * Based on code + * Copyright 2001 Patrick Mochel <mochel@osdl.org> + */ +#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 <nigel@suspend2.net> + * + * 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 <nigel@suspend2.net> + * + * 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 <nigel@suspend2.net> + * + * 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 <nigel@suspend2.net> + * + * 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 <seasons@fornax.hu> + * Copyright (C) 1998,2001,2002 Pavel Machek <pavel@suse.cz> + * Copyright (C) 2002-2003 Florent Chabaud <fchabaud@free.fr> + * Copyright (C) 2002-2005 Nigel Cunningham <nigel@suspend2.net> + * + * 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 <seasons@fornax.hu> + * Copyright (C) 1998,2001,2002 Pavel Machek <pavel@suse.cz> + * Copyright (C) 2002-2003 Florent Chabaud <fchabaud@free.fr> + * Copyright (C) 2002-2005 Nigel Cunningham <nigel@suspend2.net> + * + * 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 <ncunningham@cyclades.com> + * + * 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 <nigel@suspend2.net> + * + */ 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 <nigel@suspend.net> + * + * 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 <nigel@suspend2.net> + * + * 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 <nigel@suspend2.net> + * + * 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 <nigel@suspend2.net> + * + * 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 <nigel@suspend2.net> + * + * 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 <seasons@fornax.hu> + * Copyright (C) 1998,2001,2002 Pavel Machek <pavel@suse.cz> + * Copyright (C) 2002-2003 Florent Chabaud <fchabaud@free.fr> + * Copyright (C) 2002-2005 Nigel Cunningham <nigel@suspend2.net> + * + * 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
[parent not found: <200602191935.36844.dtor_core@ameritech.net>]
* Re: suspend2 review [was Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)] [not found] ` <200602191935.36844.dtor_core@ameritech.net> @ 2006-02-20 0:44 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 0:44 UTC (permalink / raw) To: Dmitry Torokhov Cc: Nigel Cunningham, Matthias Hensler, Sebastian Kgler, kernel list, rjw 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: suspend2 review [was Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)] 2006-02-19 23:42 ` suspend2 review [was Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)] Pavel Machek [not found] ` <200602191935.36844.dtor_core@ameritech.net> @ 2006-02-20 2:10 ` Nigel Cunningham 2006-02-20 12:49 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-20 2:10 UTC (permalink / raw) To: Pavel Machek; +Cc: Matthias Hensler, Sebastian Kgler, kernel list, rjw [-- Attachment #1: Type: text/plain, Size: 81212 bytes --] 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 <nigel@suspend2.net> > + * Based on code > + * Copyright 2001-2002 Pavel Machek <pavel@suse.cz> > + * Based on code > + * Copyright 2001 Patrick Mochel <mochel@osdl.org> > + */ > +#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 <nigel@suspend2.net> > + * > + * 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 <nigel@suspend2.net> > + * > + * 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 <nigel@suspend2.net> > + * > + * 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 <nigel@suspend2.net> > + * > + * 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 <seasons@fornax.hu> > + * Copyright (C) 1998,2001,2002 Pavel Machek <pavel@suse.cz> > + * Copyright (C) 2002-2003 Florent Chabaud <fchabaud@free.fr> > + * Copyright (C) 2002-2005 Nigel Cunningham <nigel@suspend2.net> > + * > + * 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 <seasons@fornax.hu> > + * Copyright (C) 1998,2001,2002 Pavel Machek <pavel@suse.cz> > + * Copyright (C) 2002-2003 Florent Chabaud <fchabaud@free.fr> > + * Copyright (C) 2002-2005 Nigel Cunningham <nigel@suspend2.net> > + * > + * 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 <ncunningham@cyclades.com> > + * > + * 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 <nigel@suspend2.net> > + * > + */ > > 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 <nigel@suspend.net> > + * > + * 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 <nigel@suspend2.net> > + * > + * 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 <nigel@suspend2.net> > + * > + * 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 <nigel@suspend2.net> > + * > + * 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 <nigel@suspend2.net> > + * > + * 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 <seasons@fornax.hu> > + * Copyright (C) 1998,2001,2002 Pavel Machek <pavel@suse.cz> > + * Copyright (C) 2002-2003 Florent Chabaud <fchabaud@free.fr> > + * Copyright (C) 2002-2005 Nigel Cunningham <nigel@suspend2.net> > + * > + * 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: suspend2 review [was Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)] 2006-02-20 2:10 ` Nigel Cunningham @ 2006-02-20 12:49 ` Pavel Machek 2006-02-20 17:05 ` Olivier Galibert 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-20 12:49 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Matthias Hensler, Sebastian Kgler, kernel list, rjw 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 <nigel@suspend2.net> > > + * > > + * 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 <nigel@suspend2.net> > > + * > > + * 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 <nigel@suspend.net> > > + * > > + * 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 <nigel@suspend2.net> > > + * > > + * 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 <nigel@suspend2.net> > > + * > > + * 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: suspend2 review [was Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)] 2006-02-20 12:49 ` Pavel Machek @ 2006-02-20 17:05 ` Olivier Galibert 2006-02-20 17:10 ` Pavel Machek 2006-02-21 22:02 ` Lee Revell 0 siblings, 2 replies; 432+ messages in thread From: Olivier Galibert @ 2006-02-20 17:05 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Matthias Hensler, Sebastian Kgler, kernel list, rjw 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: suspend2 review [was Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)] 2006-02-20 17:05 ` Olivier Galibert @ 2006-02-20 17:10 ` Pavel Machek 2006-02-20 18:31 ` Olivier Galibert 2006-02-21 22:02 ` Lee Revell 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-20 17:10 UTC (permalink / raw) To: Olivier Galibert, Nigel Cunningham, Matthias Hensler, Sebastian Kgler, kernel list, rjw 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: suspend2 review [was Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)] 2006-02-20 17:10 ` Pavel Machek @ 2006-02-20 18:31 ` Olivier Galibert 2006-02-20 19:43 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Olivier Galibert @ 2006-02-20 18:31 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Matthias Hensler, Sebastian Kgler, kernel list, rjw 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: suspend2 review [was Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)] 2006-02-20 18:31 ` Olivier Galibert @ 2006-02-20 19:43 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 19:43 UTC (permalink / raw) To: Olivier Galibert, Nigel Cunningham, Matthias Hensler, Sebastian Kgler, kernel list, rjw 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: suspend2 review [was Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)] 2006-02-20 17:05 ` Olivier Galibert 2006-02-20 17:10 ` Pavel Machek @ 2006-02-21 22:02 ` Lee Revell 2006-02-21 22:17 ` Dmitry Torokhov 1 sibling, 1 reply; 432+ messages in thread From: Lee Revell @ 2006-02-21 22:02 UTC (permalink / raw) To: Olivier Galibert Cc: Pavel Machek, Nigel Cunningham, Matthias Hensler, Sebastian Kgler, kernel list, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: suspend2 review [was Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)] 2006-02-21 22:02 ` Lee Revell @ 2006-02-21 22:17 ` Dmitry Torokhov 2006-02-21 22:21 ` Lee Revell 2006-02-21 23:55 ` Tristan Wibberley 0 siblings, 2 replies; 432+ messages in thread From: Dmitry Torokhov @ 2006-02-21 22:17 UTC (permalink / raw) To: Lee Revell Cc: Olivier Galibert, Pavel Machek, Nigel Cunningham, Matthias Hensler, Sebastian Kgler, kernel list, rjw On 2/21/06, Lee Revell <rlrevell@joe-job.com> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: suspend2 review [was Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)] 2006-02-21 22:17 ` Dmitry Torokhov @ 2006-02-21 22:21 ` Lee Revell 2006-02-21 23:55 ` Tristan Wibberley 1 sibling, 0 replies; 432+ messages in thread From: Lee Revell @ 2006-02-21 22:21 UTC (permalink / raw) To: dtor_core Cc: Olivier Galibert, Pavel Machek, Nigel Cunningham, Matthias Hensler, Sebastian Kgler, kernel list, rjw On Tue, 2006-02-21 at 17:17 -0500, Dmitry Torokhov wrote: > On 2/21/06, Lee Revell <rlrevell@joe-job.com> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: suspend2 review [was Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)] 2006-02-21 22:17 ` Dmitry Torokhov 2006-02-21 22:21 ` Lee Revell @ 2006-02-21 23:55 ` Tristan Wibberley 1 sibling, 0 replies; 432+ messages in thread From: Tristan Wibberley @ 2006-02-21 23:55 UTC (permalink / raw) To: linux-kernel Dmitry Torokhov wrote: > On 2/21/06, Lee Revell <rlrevell@joe-job.com> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-18 14:26 ` Pavel Machek 2006-02-19 21:09 ` Nigel Cunningham @ 2006-02-20 9:39 ` Matthias Hensler 2006-02-20 10:02 ` Lee Revell ` (4 more replies) 1 sibling, 5 replies; 432+ messages in thread From: Matthias Hensler @ 2006-02-20 9:39 UTC (permalink / raw) To: Pavel Machek; +Cc: Sebastian Kgler, kernel list, nigel, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 9:39 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Matthias Hensler @ 2006-02-20 10:02 ` Lee Revell 2006-02-20 10:10 ` Matthias Hensler ` (2 more replies) 2006-02-20 10:05 ` Sebastian Kügler ` (3 subsequent siblings) 4 siblings, 3 replies; 432+ messages in thread From: Lee Revell @ 2006-02-20 10:02 UTC (permalink / raw) To: Matthias Hensler; +Cc: Pavel Machek, Sebastian Kgler, kernel list, nigel, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:02 ` Lee Revell @ 2006-02-20 10:10 ` Matthias Hensler 2006-02-20 10:15 ` Lee Revell 2006-02-20 10:37 ` Nigel Cunningham 2006-02-20 14:01 ` Dmitry Torokhov 2 siblings, 1 reply; 432+ messages in thread From: Matthias Hensler @ 2006-02-20 10:10 UTC (permalink / raw) To: Lee Revell; +Cc: Pavel Machek, Sebastian Kgler, kernel list, nigel, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:10 ` Matthias Hensler @ 2006-02-20 10:15 ` Lee Revell 2006-02-20 10:24 ` Matthias Hensler 2006-02-20 10:44 ` Nigel Cunningham 0 siblings, 2 replies; 432+ messages in thread From: Lee Revell @ 2006-02-20 10:15 UTC (permalink / raw) To: Matthias Hensler; +Cc: Pavel Machek, Sebastian Kgler, kernel list, nigel, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:15 ` Lee Revell @ 2006-02-20 10:24 ` Matthias Hensler 2006-02-20 10:44 ` Nigel Cunningham 1 sibling, 0 replies; 432+ messages in thread From: Matthias Hensler @ 2006-02-20 10:24 UTC (permalink / raw) To: Lee Revell; +Cc: Pavel Machek, Sebastian Kgler, kernel list, nigel, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:15 ` Lee Revell 2006-02-20 10:24 ` Matthias Hensler @ 2006-02-20 10:44 ` Nigel Cunningham 2006-02-20 13:37 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-20 10:44 UTC (permalink / raw) To: Lee Revell Cc: Matthias Hensler, Pavel Machek, Sebastian Kgler, kernel list, rjw [-- Attachment #1: Type: text/plain, Size: 909 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:44 ` Nigel Cunningham @ 2006-02-20 13:37 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 13:37 UTC (permalink / raw) To: Nigel Cunningham Cc: Lee Revell, Matthias Hensler, Sebastian Kgler, kernel list, rjw 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:02 ` Lee Revell 2006-02-20 10:10 ` Matthias Hensler @ 2006-02-20 10:37 ` Nigel Cunningham 2006-02-20 13:30 ` Pavel Machek 2006-02-20 14:01 ` Dmitry Torokhov 2 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-20 10:37 UTC (permalink / raw) To: Lee Revell Cc: Matthias Hensler, Pavel Machek, Sebastian Kgler, kernel list, rjw [-- Attachment #1: Type: text/plain, Size: 860 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:37 ` Nigel Cunningham @ 2006-02-20 13:30 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 13:30 UTC (permalink / raw) To: Nigel Cunningham Cc: Lee Revell, Matthias Hensler, Sebastian Kgler, kernel list, rjw > 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:02 ` Lee Revell 2006-02-20 10:10 ` Matthias Hensler 2006-02-20 10:37 ` Nigel Cunningham @ 2006-02-20 14:01 ` Dmitry Torokhov 2006-02-20 14:22 ` Pavel Machek 2006-02-20 20:27 ` Nigel Cunningham 2 siblings, 2 replies; 432+ messages in thread From: Dmitry Torokhov @ 2006-02-20 14:01 UTC (permalink / raw) To: Lee Revell Cc: Matthias Hensler, Pavel Machek, Sebastian Kgler, kernel list, nigel, rjw On 2/20/06, Lee Revell <rlrevell@joe-job.com> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 14:01 ` Dmitry Torokhov @ 2006-02-20 14:22 ` Pavel Machek 2006-02-20 20:27 ` Nigel Cunningham 1 sibling, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 14:22 UTC (permalink / raw) To: dtor_core Cc: Lee Revell, Matthias Hensler, Sebastian Kgler, kernel list, nigel, rjw > On 2/20/06, Lee Revell <rlrevell@joe-job.com> 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 14:01 ` Dmitry Torokhov 2006-02-20 14:22 ` Pavel Machek @ 2006-02-20 20:27 ` Nigel Cunningham 1 sibling, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-20 20:27 UTC (permalink / raw) To: dtor_core Cc: Lee Revell, Matthias Hensler, Pavel Machek, Sebastian Kgler, kernel list, rjw [-- Attachment #1: Type: text/plain, Size: 1633 bytes --] Hi Dimitry. On Tuesday 21 February 2006 00:01, Dmitry Torokhov wrote: > On 2/20/06, Lee Revell <rlrevell@joe-job.com> 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 9:39 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Matthias Hensler 2006-02-20 10:02 ` Lee Revell @ 2006-02-20 10:05 ` Sebastian Kügler 2006-02-20 13:01 ` Pavel Machek 2006-02-20 10:06 ` Lee Revell ` (2 subsequent siblings) 4 siblings, 1 reply; 432+ messages in thread From: Sebastian Kügler @ 2006-02-20 10:05 UTC (permalink / raw) To: Matthias Hensler; +Cc: Pavel Machek, kernel list, nigel, rjw, suspend2-devel [-- Attachment #1: Type: text/plain, Size: 2207 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 481 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:05 ` Sebastian Kügler @ 2006-02-20 13:01 ` Pavel Machek 2006-02-20 17:01 ` Alon Bar-Lev 2006-02-20 19:12 ` Henrik Brix Andersen 0 siblings, 2 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 13:01 UTC (permalink / raw) To: Sebastian Kügler Cc: Matthias Hensler, kernel list, nigel, rjw, suspend2-devel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 13:01 ` Pavel Machek @ 2006-02-20 17:01 ` Alon Bar-Lev 2006-02-20 19:12 ` Henrik Brix Andersen 1 sibling, 0 replies; 432+ messages in thread From: Alon Bar-Lev @ 2006-02-20 17:01 UTC (permalink / raw) To: Pavel Machek Cc: Sebastian Kügler, nigel, Matthias Hensler, rjw, kernel list, suspend2-devel On 2/20/06, Pavel Machek <pavel@ucw.cz> 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 13:01 ` Pavel Machek 2006-02-20 17:01 ` Alon Bar-Lev @ 2006-02-20 19:12 ` Henrik Brix Andersen 2006-02-20 19:51 ` Theodore Ts'o 1 sibling, 1 reply; 432+ messages in thread From: Henrik Brix Andersen @ 2006-02-20 19:12 UTC (permalink / raw) To: Pavel Machek Cc: Sebastian Kügler, nigel, Matthias Hensler, rjw, kernel list, suspend2-devel [-- Attachment #1: Type: text/plain, Size: 652 bytes --] 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 <brix@gentoo.org> Gentoo Metadistribution | Mobile computing herd [-- Attachment #2: Type: application/pgp-signature, Size: 213 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 19:12 ` Henrik Brix Andersen @ 2006-02-20 19:51 ` Theodore Ts'o 2006-02-20 20:08 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Theodore Ts'o @ 2006-02-20 19:51 UTC (permalink / raw) To: Pavel Machek, Sebastian K?gler, nigel, Matthias Hensler, rjw, kernel list, suspend2-devel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 19:51 ` Theodore Ts'o @ 2006-02-20 20:08 ` Pavel Machek 2006-02-20 20:36 ` Pavel Machek 2006-02-20 20:44 ` Nigel Cunningham 0 siblings, 2 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 20:08 UTC (permalink / raw) To: Theodore Ts'o, Sebastian K?gler, nigel, Matthias Hensler, rjw, kernel list, suspend2-devel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 20:08 ` Pavel Machek @ 2006-02-20 20:36 ` Pavel Machek 2006-02-20 20:44 ` Nigel Cunningham 1 sibling, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 20:36 UTC (permalink / raw) To: Theodore Ts'o, Sebastian K?gler, nigel, Matthias Hensler, rjw, kernel list, suspend2-devel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 20:08 ` Pavel Machek 2006-02-20 20:36 ` Pavel Machek @ 2006-02-20 20:44 ` Nigel Cunningham 2006-02-20 20:59 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-20 20:44 UTC (permalink / raw) To: Pavel Machek Cc: Theodore Ts'o, Sebastian K?gler, Matthias Hensler, rjw, kernel list, suspend2-devel [-- Attachment #1: Type: text/plain, Size: 962 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 20:44 ` Nigel Cunningham @ 2006-02-20 20:59 ` Pavel Machek 2006-02-20 21:01 ` Nigel Cunningham 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-20 20:59 UTC (permalink / raw) To: Nigel Cunningham Cc: Theodore Ts'o, Sebastian K?gler, Matthias Hensler, rjw, kernel list, suspend2-devel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 20:59 ` Pavel Machek @ 2006-02-20 21:01 ` Nigel Cunningham 0 siblings, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-20 21:01 UTC (permalink / raw) To: Pavel Machek Cc: Theodore Ts'o, Sebastian K?gler, Matthias Hensler, rjw, kernel list, suspend2-devel [-- Attachment #1: Type: text/plain, Size: 942 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 9:39 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Matthias Hensler 2006-02-20 10:02 ` Lee Revell 2006-02-20 10:05 ` Sebastian Kügler @ 2006-02-20 10:06 ` Lee Revell 2006-02-20 10:15 ` Matthias Hensler 2006-02-20 10:38 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Nigel Cunningham 2006-02-20 10:11 ` Lee Revell 2006-02-20 12:56 ` Pavel Machek 4 siblings, 2 replies; 432+ messages in thread From: Lee Revell @ 2006-02-20 10:06 UTC (permalink / raw) To: Matthias Hensler; +Cc: Pavel Machek, Sebastian Kgler, kernel list, nigel, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:06 ` Lee Revell @ 2006-02-20 10:15 ` Matthias Hensler 2006-02-20 10:24 ` Lee Revell 2006-02-20 10:38 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Nigel Cunningham 1 sibling, 1 reply; 432+ messages in thread From: Matthias Hensler @ 2006-02-20 10:15 UTC (permalink / raw) To: Lee Revell; +Cc: Pavel Machek, Sebastian Kgler, kernel list, nigel, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:15 ` Matthias Hensler @ 2006-02-20 10:24 ` Lee Revell 2006-02-20 10:33 ` Matthias Hensler 0 siblings, 1 reply; 432+ messages in thread From: Lee Revell @ 2006-02-20 10:24 UTC (permalink / raw) To: Matthias Hensler; +Cc: Pavel Machek, Sebastian Kgler, kernel list, nigel, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:24 ` Lee Revell @ 2006-02-20 10:33 ` Matthias Hensler 2006-02-20 11:15 ` Lee Revell 0 siblings, 1 reply; 432+ messages in thread From: Matthias Hensler @ 2006-02-20 10:33 UTC (permalink / raw) To: Lee Revell; +Cc: Pavel Machek, Sebastian Kgler, kernel list, nigel, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:33 ` Matthias Hensler @ 2006-02-20 11:15 ` Lee Revell 2006-02-20 11:24 ` Nigel Cunningham 2006-02-20 12:24 ` Matthias Hensler 0 siblings, 2 replies; 432+ messages in thread From: Lee Revell @ 2006-02-20 11:15 UTC (permalink / raw) To: Matthias Hensler; +Cc: Pavel Machek, Sebastian Kgler, kernel list, nigel, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 11:15 ` Lee Revell @ 2006-02-20 11:24 ` Nigel Cunningham 2006-02-20 13:23 ` Pavel Machek 2006-02-20 12:24 ` Matthias Hensler 1 sibling, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-20 11:24 UTC (permalink / raw) To: Lee Revell Cc: Matthias Hensler, Pavel Machek, Sebastian Kgler, kernel list, rjw [-- Attachment #1: Type: text/plain, Size: 1320 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 11:24 ` Nigel Cunningham @ 2006-02-20 13:23 ` Pavel Machek 2006-02-20 14:23 ` Mark Lord 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-20 13:23 UTC (permalink / raw) To: Nigel Cunningham Cc: Lee Revell, Matthias Hensler, Sebastian Kgler, kernel list, rjw > 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 13:23 ` Pavel Machek @ 2006-02-20 14:23 ` Mark Lord 2006-02-20 14:30 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Mark Lord @ 2006-02-20 14:23 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Lee Revell, Matthias Hensler, Sebastian Kgler, kernel list, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 14:23 ` Mark Lord @ 2006-02-20 14:30 ` Pavel Machek 2006-02-20 14:41 ` Dmitry Torokhov 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-20 14:30 UTC (permalink / raw) To: Mark Lord Cc: Nigel Cunningham, Lee Revell, Matthias Hensler, Sebastian Kgler, kernel list, rjw > 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 14:30 ` Pavel Machek @ 2006-02-20 14:41 ` Dmitry Torokhov 2006-02-20 14:54 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Dmitry Torokhov @ 2006-02-20 14:41 UTC (permalink / raw) To: Pavel Machek Cc: Mark Lord, Nigel Cunningham, Lee Revell, Matthias Hensler, Sebastian Kgler, kernel list, rjw On 2/20/06, Pavel Machek <pavel@ucw.cz> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 14:41 ` Dmitry Torokhov @ 2006-02-20 14:54 ` Pavel Machek 2006-02-20 15:08 ` Dmitry Torokhov 2006-02-20 19:45 ` Lee Revell 0 siblings, 2 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 14:54 UTC (permalink / raw) To: dtor_core Cc: Mark Lord, Nigel Cunningham, Lee Revell, Matthias Hensler, Sebastian Kgler, kernel list, rjw > On 2/20/06, Pavel Machek <pavel@ucw.cz> 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 14:54 ` Pavel Machek @ 2006-02-20 15:08 ` Dmitry Torokhov 2006-02-20 16:22 ` Rafael J. Wysocki 2006-02-20 19:45 ` Lee Revell 1 sibling, 1 reply; 432+ messages in thread From: Dmitry Torokhov @ 2006-02-20 15:08 UTC (permalink / raw) To: Pavel Machek Cc: Mark Lord, Nigel Cunningham, Lee Revell, Matthias Hensler, Sebastian Kgler, kernel list, rjw On 2/20/06, Pavel Machek <pavel@ucw.cz> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 15:08 ` Dmitry Torokhov @ 2006-02-20 16:22 ` Rafael J. Wysocki 2006-02-20 16:30 ` Dmitry Torokhov 2006-02-20 19:46 ` Lee Revell 0 siblings, 2 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-20 16:22 UTC (permalink / raw) To: dtor_core Cc: Pavel Machek, Mark Lord, Nigel Cunningham, Lee Revell, Matthias Hensler, Sebastian Kgler, kernel list On Monday 20 February 2006 16:08, Dmitry Torokhov wrote: > On 2/20/06, Pavel Machek <pavel@ucw.cz> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 16:22 ` Rafael J. Wysocki @ 2006-02-20 16:30 ` Dmitry Torokhov 2006-02-20 17:23 ` Rafael J. Wysocki 2006-02-20 19:46 ` Lee Revell 1 sibling, 1 reply; 432+ messages in thread From: Dmitry Torokhov @ 2006-02-20 16:30 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Pavel Machek, Mark Lord, Nigel Cunningham, Lee Revell, Matthias Hensler, Sebastian Kgler, kernel list On 2/20/06, Rafael J. Wysocki <rjw@sisk.pl> wrote: > On Monday 20 February 2006 16:08, Dmitry Torokhov wrote: > > On 2/20/06, Pavel Machek <pavel@ucw.cz> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 16:30 ` Dmitry Torokhov @ 2006-02-20 17:23 ` Rafael J. Wysocki 2006-02-20 17:33 ` Dmitry Torokhov 0 siblings, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-20 17:23 UTC (permalink / raw) To: dtor_core Cc: Pavel Machek, Mark Lord, Nigel Cunningham, Lee Revell, Matthias Hensler, Sebastian Kgler, kernel list On Monday 20 February 2006 17:30, Dmitry Torokhov wrote: > On 2/20/06, Rafael J. Wysocki <rjw@sisk.pl> wrote: > > On Monday 20 February 2006 16:08, Dmitry Torokhov wrote: > > > On 2/20/06, Pavel Machek <pavel@ucw.cz> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 17:23 ` Rafael J. Wysocki @ 2006-02-20 17:33 ` Dmitry Torokhov 2006-02-20 18:19 ` Rafael J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Dmitry Torokhov @ 2006-02-20 17:33 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Pavel Machek, Mark Lord, Nigel Cunningham, Lee Revell, Matthias Hensler, Sebastian Kgler, kernel list On 2/20/06, Rafael J. Wysocki <rjw@sisk.pl> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 17:33 ` Dmitry Torokhov @ 2006-02-20 18:19 ` Rafael J. Wysocki 0 siblings, 0 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-20 18:19 UTC (permalink / raw) To: dtor_core Cc: Pavel Machek, Mark Lord, Nigel Cunningham, Lee Revell, Matthias Hensler, Sebastian Kgler, kernel list On Monday 20 February 2006 18:33, Dmitry Torokhov wrote: > On 2/20/06, Rafael J. Wysocki <rjw@sisk.pl> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 16:22 ` Rafael J. Wysocki 2006-02-20 16:30 ` Dmitry Torokhov @ 2006-02-20 19:46 ` Lee Revell 1 sibling, 0 replies; 432+ messages in thread From: Lee Revell @ 2006-02-20 19:46 UTC (permalink / raw) To: Rafael J. Wysocki Cc: dtor_core, Pavel Machek, Mark Lord, Nigel Cunningham, Matthias Hensler, Sebastian Kgler, kernel list 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 14:54 ` Pavel Machek 2006-02-20 15:08 ` Dmitry Torokhov @ 2006-02-20 19:45 ` Lee Revell 2006-02-20 20:11 ` Rafael J. Wysocki 2006-02-20 20:15 ` Dmitry Torokhov 1 sibling, 2 replies; 432+ messages in thread From: Lee Revell @ 2006-02-20 19:45 UTC (permalink / raw) To: Pavel Machek Cc: dtor_core, Mark Lord, Nigel Cunningham, Matthias Hensler, Sebastian Kgler, kernel list, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 19:45 ` Lee Revell @ 2006-02-20 20:11 ` Rafael J. Wysocki 2006-02-20 20:15 ` Dmitry Torokhov 1 sibling, 0 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-20 20:11 UTC (permalink / raw) To: Lee Revell Cc: Pavel Machek, dtor_core, Mark Lord, Nigel Cunningham, Matthias Hensler, Sebastian Kgler, kernel list 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 19:45 ` Lee Revell 2006-02-20 20:11 ` Rafael J. Wysocki @ 2006-02-20 20:15 ` Dmitry Torokhov 2006-02-20 20:30 ` Rafael J. Wysocki 2006-02-20 20:40 ` Lee Revell 1 sibling, 2 replies; 432+ messages in thread From: Dmitry Torokhov @ 2006-02-20 20:15 UTC (permalink / raw) To: Lee Revell Cc: Pavel Machek, Mark Lord, Nigel Cunningham, Matthias Hensler, Sebastian Kgler, kernel list, rjw On 2/20/06, Lee Revell <rlrevell@joe-job.com> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 20:15 ` Dmitry Torokhov @ 2006-02-20 20:30 ` Rafael J. Wysocki 2006-02-20 20:40 ` Lee Revell 1 sibling, 0 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-20 20:30 UTC (permalink / raw) To: dtor_core Cc: Lee Revell, Pavel Machek, Mark Lord, Nigel Cunningham, Matthias Hensler, Sebastian Kgler, kernel list On Monday 20 February 2006 21:15, Dmitry Torokhov wrote: > On 2/20/06, Lee Revell <rlrevell@joe-job.com> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 20:15 ` Dmitry Torokhov 2006-02-20 20:30 ` Rafael J. Wysocki @ 2006-02-20 20:40 ` Lee Revell 1 sibling, 0 replies; 432+ messages in thread From: Lee Revell @ 2006-02-20 20:40 UTC (permalink / raw) To: dtor_core Cc: Pavel Machek, Mark Lord, Nigel Cunningham, Matthias Hensler, Sebastian Kgler, kernel list, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 11:15 ` Lee Revell 2006-02-20 11:24 ` Nigel Cunningham @ 2006-02-20 12:24 ` Matthias Hensler 2006-02-20 13:28 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Matthias Hensler @ 2006-02-20 12:24 UTC (permalink / raw) To: Lee Revell; +Cc: Pavel Machek, Sebastian Kgler, kernel list, nigel, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 12:24 ` Matthias Hensler @ 2006-02-20 13:28 ` Pavel Machek 2006-02-20 13:51 ` Matthias Hensler 2006-02-20 14:08 ` Which is simpler? Harald Arnesen 0 siblings, 2 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 13:28 UTC (permalink / raw) To: Matthias Hensler; +Cc: Lee Revell, Sebastian Kgler, kernel list, nigel, rjw > 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 13:28 ` Pavel Machek @ 2006-02-20 13:51 ` Matthias Hensler 2006-02-20 14:07 ` Pavel Machek 2006-02-22 16:15 ` agp fixes in suspend2 patch Thierry Vignaud 2006-02-20 14:08 ` Which is simpler? Harald Arnesen 1 sibling, 2 replies; 432+ messages in thread From: Matthias Hensler @ 2006-02-20 13:51 UTC (permalink / raw) To: Pavel Machek; +Cc: Lee Revell, Sebastian Kgler, kernel list, nigel, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 13:51 ` Matthias Hensler @ 2006-02-20 14:07 ` Pavel Machek 2006-02-20 14:42 ` Matthias Hensler 2006-02-22 16:15 ` agp fixes in suspend2 patch Thierry Vignaud 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-20 14:07 UTC (permalink / raw) To: Matthias Hensler; +Cc: Lee Revell, Sebastian Kgler, kernel list, nigel, rjw > 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 14:07 ` Pavel Machek @ 2006-02-20 14:42 ` Matthias Hensler 2006-02-20 15:01 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Matthias Hensler @ 2006-02-20 14:42 UTC (permalink / raw) To: Pavel Machek; +Cc: Lee Revell, Sebastian Kgler, kernel list, nigel, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 14:42 ` Matthias Hensler @ 2006-02-20 15:01 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 15:01 UTC (permalink / raw) To: Matthias Hensler; +Cc: Lee Revell, Sebastian Kgler, kernel list, nigel, rjw 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* agp fixes in suspend2 patch 2006-02-20 13:51 ` Matthias Hensler 2006-02-20 14:07 ` Pavel Machek @ 2006-02-22 16:15 ` Thierry Vignaud 2006-02-23 19:04 ` Dave Jones 1 sibling, 1 reply; 432+ messages in thread From: Thierry Vignaud @ 2006-02-22 16:15 UTC (permalink / raw) To: Matthias Hensler Cc: Pavel Machek, Lee Revell, Sebastian Kgler, kernel list, nigel, rjw Matthias Hensler <matthias@wspse.de> 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). ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: agp fixes in suspend2 patch 2006-02-22 16:15 ` agp fixes in suspend2 patch Thierry Vignaud @ 2006-02-23 19:04 ` Dave Jones 0 siblings, 0 replies; 432+ messages in thread From: Dave Jones @ 2006-02-23 19:04 UTC (permalink / raw) To: Thierry Vignaud Cc: Matthias Hensler, Pavel Machek, Lee Revell, Sebastian Kgler, kernel list, nigel, rjw On Wed, Feb 22, 2006 at 05:15:26PM +0100, Thierry Vignaud wrote: > Matthias Hensler <matthias@wspse.de> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? 2006-02-20 13:28 ` Pavel Machek 2006-02-20 13:51 ` Matthias Hensler @ 2006-02-20 14:08 ` Harald Arnesen 2006-02-20 14:42 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Harald Arnesen @ 2006-02-20 14:08 UTC (permalink / raw) To: Pavel Machek Cc: Matthias Hensler, Lee Revell, Sebastian Kgler, kernel list, nigel, rjw Pavel Machek <pavel@ucw.cz> 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? 2006-02-20 14:08 ` Which is simpler? Harald Arnesen @ 2006-02-20 14:42 ` Pavel Machek 2006-02-20 14:49 ` Matthias Hensler 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-20 14:42 UTC (permalink / raw) To: Harald Arnesen Cc: Matthias Hensler, Lee Revell, Sebastian Kgler, kernel list, nigel, rjw > Pavel Machek <pavel@ucw.cz> 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? 2006-02-20 14:42 ` Pavel Machek @ 2006-02-20 14:49 ` Matthias Hensler 2006-02-20 14:56 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Matthias Hensler @ 2006-02-20 14:49 UTC (permalink / raw) To: Pavel Machek Cc: Harald Arnesen, Lee Revell, Sebastian Kgler, kernel list, nigel, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? 2006-02-20 14:49 ` Matthias Hensler @ 2006-02-20 14:56 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 14:56 UTC (permalink / raw) To: Matthias Hensler Cc: Harald Arnesen, Lee Revell, Sebastian Kgler, kernel list, nigel, rjw > 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 www.sf.net/projects/suspend/ , then check out code from CVS, there's nice description how to do that there. Pavel -- Thanks, Sharp! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:06 ` Lee Revell 2006-02-20 10:15 ` Matthias Hensler @ 2006-02-20 10:38 ` Nigel Cunningham 2006-02-20 13:30 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-20 10:38 UTC (permalink / raw) To: Lee Revell Cc: Matthias Hensler, Pavel Machek, Sebastian Kgler, kernel list, rjw [-- Attachment #1: Type: text/plain, Size: 1049 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:38 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Nigel Cunningham @ 2006-02-20 13:30 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 13:30 UTC (permalink / raw) To: Nigel Cunningham Cc: Lee Revell, Matthias Hensler, Sebastian Kgler, kernel list, rjw > 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 9:39 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Matthias Hensler ` (2 preceding siblings ...) 2006-02-20 10:06 ` Lee Revell @ 2006-02-20 10:11 ` Lee Revell 2006-02-20 10:20 ` Matthias Hensler 2006-02-20 10:40 ` Nigel Cunningham 2006-02-20 12:56 ` Pavel Machek 4 siblings, 2 replies; 432+ messages in thread From: Lee Revell @ 2006-02-20 10:11 UTC (permalink / raw) To: Matthias Hensler; +Cc: Pavel Machek, Sebastian Kgler, kernel list, nigel, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:11 ` Lee Revell @ 2006-02-20 10:20 ` Matthias Hensler 2006-02-20 13:03 ` Pavel Machek 2006-02-20 10:40 ` Nigel Cunningham 1 sibling, 1 reply; 432+ messages in thread From: Matthias Hensler @ 2006-02-20 10:20 UTC (permalink / raw) To: Lee Revell; +Cc: Pavel Machek, Sebastian Kgler, kernel list, nigel, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:20 ` Matthias Hensler @ 2006-02-20 13:03 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 13:03 UTC (permalink / raw) To: Matthias Hensler; +Cc: Lee Revell, Sebastian Kgler, kernel list, nigel, rjw 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:11 ` Lee Revell 2006-02-20 10:20 ` Matthias Hensler @ 2006-02-20 10:40 ` Nigel Cunningham 2006-02-20 12:05 ` Lee Revell 1 sibling, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-20 10:40 UTC (permalink / raw) To: Lee Revell Cc: Matthias Hensler, Pavel Machek, Sebastian Kgler, kernel list, rjw [-- Attachment #1: Type: text/plain, Size: 1496 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 10:40 ` Nigel Cunningham @ 2006-02-20 12:05 ` Lee Revell 2006-02-20 12:26 ` Matthias Hensler 2006-02-20 12:31 ` Olivier Galibert 0 siblings, 2 replies; 432+ messages in thread From: Lee Revell @ 2006-02-20 12:05 UTC (permalink / raw) To: Nigel Cunningham Cc: Matthias Hensler, Pavel Machek, Sebastian Kgler, kernel list, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 12:05 ` Lee Revell @ 2006-02-20 12:26 ` Matthias Hensler 2006-02-20 12:31 ` Olivier Galibert 1 sibling, 0 replies; 432+ messages in thread From: Matthias Hensler @ 2006-02-20 12:26 UTC (permalink / raw) To: Lee Revell Cc: Nigel Cunningham, Pavel Machek, Sebastian Kgler, kernel list, rjw 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 12:05 ` Lee Revell 2006-02-20 12:26 ` Matthias Hensler @ 2006-02-20 12:31 ` Olivier Galibert 2006-02-20 14:13 ` Rafael J. Wysocki 1 sibling, 1 reply; 432+ messages in thread From: Olivier Galibert @ 2006-02-20 12:31 UTC (permalink / raw) To: kernel list 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 12:31 ` Olivier Galibert @ 2006-02-20 14:13 ` Rafael J. Wysocki 2006-02-20 15:39 ` Olivier Galibert 0 siblings, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-20 14:13 UTC (permalink / raw) To: Olivier Galibert; +Cc: kernel list, Pavel Machek 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 14:13 ` Rafael J. Wysocki @ 2006-02-20 15:39 ` Olivier Galibert 2006-02-20 16:27 ` Andreas Happe ` (2 more replies) 0 siblings, 3 replies; 432+ messages in thread From: Olivier Galibert @ 2006-02-20 15:39 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: kernel list, Pavel Machek 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 15:39 ` Olivier Galibert @ 2006-02-20 16:27 ` Andreas Happe 2006-02-20 17:36 ` Olivier Galibert 2006-02-20 16:41 ` Which is simpler? (Was Re: [Suspend2-devel] " Pavel Machek 2006-02-20 17:16 ` Rafael J. Wysocki 2 siblings, 1 reply; 432+ messages in thread From: Andreas Happe @ 2006-02-20 16:27 UTC (permalink / raw) To: linux-kernel On 2006-02-20, Olivier Galibert <galibert@pobox.com> 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/ ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 16:27 ` Andreas Happe @ 2006-02-20 17:36 ` Olivier Galibert 2006-02-21 0:52 ` Andreas Happe 0 siblings, 1 reply; 432+ messages in thread From: Olivier Galibert @ 2006-02-20 17:36 UTC (permalink / raw) To: Andreas Happe; +Cc: linux-kernel 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 17:36 ` Olivier Galibert @ 2006-02-21 0:52 ` Andreas Happe 2006-02-21 2:57 ` Nigel Cunningham 0 siblings, 1 reply; 432+ messages in thread From: Andreas Happe @ 2006-02-21 0:52 UTC (permalink / raw) To: linux-kernel On 2006-02-20, Olivier Galibert <galibert@pobox.com> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-21 0:52 ` Andreas Happe @ 2006-02-21 2:57 ` Nigel Cunningham 2006-02-21 4:19 ` Dmitry Torokhov 2006-02-21 12:59 ` Which is simpler? (Was " Andreas Happe 0 siblings, 2 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-21 2:57 UTC (permalink / raw) To: Andreas Happe; +Cc: linux-kernel, Suspend2 Devel List [-- Attachment #1: Type: text/plain, Size: 2009 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-21 2:57 ` Nigel Cunningham @ 2006-02-21 4:19 ` Dmitry Torokhov 2006-02-21 5:51 ` Nigel Cunningham 2006-02-21 20:40 ` Rafael J. Wysocki 2006-02-21 12:59 ` Which is simpler? (Was " Andreas Happe 1 sibling, 2 replies; 432+ messages in thread From: Dmitry Torokhov @ 2006-02-21 4:19 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Andreas Happe, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-21 4:19 ` Dmitry Torokhov @ 2006-02-21 5:51 ` Nigel Cunningham 2006-02-21 12:27 ` Pavel Machek 2006-02-21 20:40 ` Rafael J. Wysocki 1 sibling, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-21 5:51 UTC (permalink / raw) To: Dmitry Torokhov; +Cc: Andreas Happe, linux-kernel, Suspend2 Devel List [-- Attachment #1: Type: text/plain, Size: 1058 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-21 5:51 ` Nigel Cunningham @ 2006-02-21 12:27 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-21 12:27 UTC (permalink / raw) To: Nigel Cunningham Cc: Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-21 4:19 ` Dmitry Torokhov 2006-02-21 5:51 ` Nigel Cunningham @ 2006-02-21 20:40 ` Rafael J. Wysocki 2006-02-21 21:00 ` Nigel Cunningham 1 sibling, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-21 20:40 UTC (permalink / raw) To: Dmitry Torokhov Cc: Nigel Cunningham, Andreas Happe, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-21 20:40 ` Rafael J. Wysocki @ 2006-02-21 21:00 ` Nigel Cunningham 2006-02-21 23:38 ` Rafael J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-21 21:00 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List [-- Attachment #1: Type: text/plain, Size: 1448 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-21 21:00 ` Nigel Cunningham @ 2006-02-21 23:38 ` Rafael J. Wysocki 2006-02-21 23:47 ` Nigel Cunningham 2006-02-22 22:24 ` Pavel Machek 0 siblings, 2 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-21 23:38 UTC (permalink / raw) To: Nigel Cunningham Cc: Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-21 23:38 ` Rafael J. Wysocki @ 2006-02-21 23:47 ` Nigel Cunningham 2006-02-22 18:49 ` Rafael J. Wysocki 2006-02-22 22:24 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-21 23:47 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List [-- Attachment #1: Type: text/plain, Size: 3291 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-21 23:47 ` Nigel Cunningham @ 2006-02-22 18:49 ` Rafael J. Wysocki 2006-02-22 22:41 ` Nigel Cunningham 0 siblings, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-22 18:49 UTC (permalink / raw) To: Nigel Cunningham Cc: Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-22 18:49 ` Rafael J. Wysocki @ 2006-02-22 22:41 ` Nigel Cunningham 2006-02-22 23:45 ` Rafael J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-22 22:41 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List [-- Attachment #1: Type: text/plain, Size: 3222 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-22 22:41 ` Nigel Cunningham @ 2006-02-22 23:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-22 23:45 UTC (permalink / raw) To: Nigel Cunningham Cc: Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-21 23:38 ` Rafael J. Wysocki 2006-02-21 23:47 ` Nigel Cunningham @ 2006-02-22 22:24 ` Pavel Machek 2006-02-22 23:31 ` Rafael J. Wysocki 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-22 22:24 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Nigel Cunningham, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-22 22:24 ` Pavel Machek @ 2006-02-22 23:31 ` Rafael J. Wysocki 2006-02-22 23:56 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-22 23:31 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-22 23:31 ` Rafael J. Wysocki @ 2006-02-22 23:56 ` Pavel Machek 2006-02-23 0:11 ` Nigel Cunningham 2006-02-23 8:44 ` Rafael J. Wysocki 0 siblings, 2 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-22 23:56 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Nigel Cunningham, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-22 23:56 ` Pavel Machek @ 2006-02-23 0:11 ` Nigel Cunningham 2006-02-23 0:33 ` Pavel Machek 2006-02-23 8:44 ` Rafael J. Wysocki 1 sibling, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-23 0:11 UTC (permalink / raw) To: Pavel Machek Cc: Rafael J. Wysocki, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List [-- Attachment #1: Type: text/plain, Size: 1057 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-23 0:11 ` Nigel Cunningham @ 2006-02-23 0:33 ` Pavel Machek 2006-02-23 0:39 ` Nigel Cunningham 2006-02-23 8:33 ` Rafael J. Wysocki 0 siblings, 2 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-23 0:33 UTC (permalink / raw) To: Nigel Cunningham Cc: Rafael J. Wysocki, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-23 0:33 ` Pavel Machek @ 2006-02-23 0:39 ` Nigel Cunningham 2006-02-23 8:33 ` Rafael J. Wysocki 1 sibling, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-23 0:39 UTC (permalink / raw) To: Pavel Machek Cc: Rafael J. Wysocki, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List [-- Attachment #1: Type: text/plain, Size: 1583 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-23 0:33 ` Pavel Machek 2006-02-23 0:39 ` Nigel Cunningham @ 2006-02-23 8:33 ` Rafael J. Wysocki 1 sibling, 0 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-23 8:33 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-22 23:56 ` Pavel Machek 2006-02-23 0:11 ` Nigel Cunningham @ 2006-02-23 8:44 ` Rafael J. Wysocki 2006-02-23 12:17 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-23 8:44 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-23 8:44 ` Rafael J. Wysocki @ 2006-02-23 12:17 ` Pavel Machek 2006-02-23 22:37 ` Rafael J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-23 12:17 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Nigel Cunningham, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-23 12:17 ` Pavel Machek @ 2006-02-23 22:37 ` Rafael J. Wysocki 2006-02-23 23:04 ` Pavel Machek 2006-02-23 23:16 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Nigel Cunningham 0 siblings, 2 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-23 22:37 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-23 22:37 ` Rafael J. Wysocki @ 2006-02-23 23:04 ` Pavel Machek 2006-02-23 23:27 ` Nigel Cunningham 2006-02-23 23:16 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Nigel Cunningham 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-23 23:04 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Nigel Cunningham, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-23 23:04 ` Pavel Machek @ 2006-02-23 23:27 ` Nigel Cunningham 2006-02-23 23:44 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-23 23:27 UTC (permalink / raw) To: Pavel Machek Cc: Rafael J. Wysocki, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List [-- Attachment #1: Type: text/plain, Size: 1695 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-23 23:27 ` Nigel Cunningham @ 2006-02-23 23:44 ` Pavel Machek 2006-02-24 10:58 ` Rafael J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-23 23:44 UTC (permalink / raw) To: Nigel Cunningham Cc: Rafael J. Wysocki, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-23 23:44 ` Pavel Machek @ 2006-02-24 10:58 ` Rafael J. Wysocki 2006-02-24 13:12 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-24 10:58 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-24 10:58 ` Rafael J. Wysocki @ 2006-02-24 13:12 ` Pavel Machek 2006-02-24 20:22 ` Rafael J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-24 13:12 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Nigel Cunningham, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-24 13:12 ` Pavel Machek @ 2006-02-24 20:22 ` Rafael J. Wysocki 2006-02-24 23:11 ` Nigel Cunningham 2006-02-24 23:55 ` Pavel Machek 0 siblings, 2 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-24 20:22 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-24 20:22 ` Rafael J. Wysocki @ 2006-02-24 23:11 ` Nigel Cunningham 2006-02-24 23:53 ` Pavel Machek 2006-02-25 0:20 ` Rafael J. Wysocki 2006-02-24 23:55 ` Pavel Machek 1 sibling, 2 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-24 23:11 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Pavel Machek, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List [-- Attachment #1: Type: text/plain, Size: 3963 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-24 23:11 ` Nigel Cunningham @ 2006-02-24 23:53 ` Pavel Machek 2006-02-25 0:15 ` Pavel Machek 2006-02-25 0:22 ` Nigel Cunningham 2006-02-25 0:20 ` Rafael J. Wysocki 1 sibling, 2 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-24 23:53 UTC (permalink / raw) To: Nigel Cunningham Cc: Rafael J. Wysocki, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-24 23:53 ` Pavel Machek @ 2006-02-25 0:15 ` Pavel Machek 2006-02-25 0:45 ` Rafael J. Wysocki 2006-02-25 0:22 ` Nigel Cunningham 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-25 0:15 UTC (permalink / raw) To: Nigel Cunningham Cc: Rafael J. Wysocki, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-25 0:15 ` Pavel Machek @ 2006-02-25 0:45 ` Rafael J. Wysocki 0 siblings, 0 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-25 0:45 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Dmitry Torokhov, Andreas Happe, linux-kernel, Userland Suspend Devel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-24 23:53 ` Pavel Machek 2006-02-25 0:15 ` Pavel Machek @ 2006-02-25 0:22 ` Nigel Cunningham 2006-02-25 0:43 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-25 0:22 UTC (permalink / raw) To: Pavel Machek Cc: Rafael J. Wysocki, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List [-- Attachment #1: Type: text/plain, Size: 1070 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-25 0:22 ` Nigel Cunningham @ 2006-02-25 0:43 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-25 0:43 UTC (permalink / raw) To: Nigel Cunningham Cc: Rafael J. Wysocki, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-24 23:11 ` Nigel Cunningham 2006-02-24 23:53 ` Pavel Machek @ 2006-02-25 0:20 ` Rafael J. Wysocki 2006-02-25 0:26 ` Nigel Cunningham 1 sibling, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-25 0:20 UTC (permalink / raw) To: Nigel Cunningham Cc: Pavel Machek, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-25 0:20 ` Rafael J. Wysocki @ 2006-02-25 0:26 ` Nigel Cunningham 2006-02-25 0:46 ` Pavel Machek 2006-02-25 0:56 ` Rafael J. Wysocki 0 siblings, 2 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-25 0:26 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Pavel Machek, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List [-- Attachment #1: Type: text/plain, Size: 3371 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-25 0:26 ` Nigel Cunningham @ 2006-02-25 0:46 ` Pavel Machek 2006-02-25 0:56 ` Rafael J. Wysocki 1 sibling, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-25 0:46 UTC (permalink / raw) To: Nigel Cunningham Cc: Rafael J. Wysocki, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-25 0:26 ` Nigel Cunningham 2006-02-25 0:46 ` Pavel Machek @ 2006-02-25 0:56 ` Rafael J. Wysocki 2006-02-25 5:13 ` Nigel Cunningham 1 sibling, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-25 0:56 UTC (permalink / raw) To: Nigel Cunningham Cc: Pavel Machek, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-25 0:56 ` Rafael J. Wysocki @ 2006-02-25 5:13 ` Nigel Cunningham 0 siblings, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-25 5:13 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Pavel Machek, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List [-- Attachment #1: Type: text/plain, Size: 4082 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-24 20:22 ` Rafael J. Wysocki 2006-02-24 23:11 ` Nigel Cunningham @ 2006-02-24 23:55 ` Pavel Machek 2006-02-26 15:27 ` [RFC/RFT][PATCH -mm] swsusp: improve memory shrinking Rafael J. Wysocki 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-24 23:55 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Nigel Cunningham, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* [RFC/RFT][PATCH -mm] swsusp: improve memory shrinking 2006-02-24 23:55 ` Pavel Machek @ 2006-02-26 15:27 ` Rafael J. Wysocki 2006-02-26 18:53 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-26 15:27 UTC (permalink / raw) To: Pavel Machek; +Cc: Nigel Cunningham, linux-kernel 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 <rjw@sisk.pl> --- 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); ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [RFC/RFT][PATCH -mm] swsusp: improve memory shrinking 2006-02-26 15:27 ` [RFC/RFT][PATCH -mm] swsusp: improve memory shrinking Rafael J. Wysocki @ 2006-02-26 18:53 ` Pavel Machek 2006-02-26 23:32 ` Rafael J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-26 18:53 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Nigel Cunningham, linux-kernel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [RFC/RFT][PATCH -mm] swsusp: improve memory shrinking 2006-02-26 18:53 ` Pavel Machek @ 2006-02-26 23:32 ` Rafael J. Wysocki 2006-02-26 23:38 ` Rafael J. Wysocki 2006-02-26 23:52 ` Pavel Machek 0 siblings, 2 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-26 23:32 UTC (permalink / raw) To: Pavel Machek; +Cc: Nigel Cunningham, linux-kernel 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 <rjw@sisk.pl> --- 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); ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [RFC/RFT][PATCH -mm] swsusp: improve memory shrinking 2006-02-26 23:32 ` Rafael J. Wysocki @ 2006-02-26 23:38 ` Rafael J. Wysocki 2006-02-26 23:56 ` Pavel Machek 2006-02-26 23:52 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-26 23:38 UTC (permalink / raw) To: Pavel Machek; +Cc: Nigel Cunningham, linux-kernel 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 <rjw@sisk.pl> --- 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]); ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [RFC/RFT][PATCH -mm] swsusp: improve memory shrinking 2006-02-26 23:38 ` Rafael J. Wysocki @ 2006-02-26 23:56 ` Pavel Machek 2006-02-27 0:13 ` Rafael J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-26 23:56 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: kernel list 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [RFC/RFT][PATCH -mm] swsusp: improve memory shrinking 2006-02-26 23:56 ` Pavel Machek @ 2006-02-27 0:13 ` Rafael J. Wysocki 0 siblings, 0 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-27 0:13 UTC (permalink / raw) To: Pavel Machek; +Cc: kernel list 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [RFC/RFT][PATCH -mm] swsusp: improve memory shrinking 2006-02-26 23:32 ` Rafael J. Wysocki 2006-02-26 23:38 ` Rafael J. Wysocki @ 2006-02-26 23:52 ` Pavel Machek 2006-02-27 0:06 ` Rafael J. Wysocki 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-26 23:52 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: kernel list 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [RFC/RFT][PATCH -mm] swsusp: improve memory shrinking 2006-02-26 23:52 ` Pavel Machek @ 2006-02-27 0:06 ` Rafael J. Wysocki 0 siblings, 0 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-27 0:06 UTC (permalink / raw) To: Pavel Machek; +Cc: kernel list 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-23 22:37 ` Rafael J. Wysocki 2006-02-23 23:04 ` Pavel Machek @ 2006-02-23 23:16 ` Nigel Cunningham 1 sibling, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-23 23:16 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Pavel Machek, Dmitry Torokhov, Andreas Happe, linux-kernel, Suspend2 Devel List [-- Attachment #1: Type: text/plain, Size: 1803 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: Re: [ 00/10] [Suspend2] Modules support.) 2006-02-21 2:57 ` Nigel Cunningham 2006-02-21 4:19 ` Dmitry Torokhov @ 2006-02-21 12:59 ` Andreas Happe 2006-02-22 0:33 ` Nigel Cunningham 1 sibling, 1 reply; 432+ messages in thread From: Andreas Happe @ 2006-02-21 12:59 UTC (permalink / raw) To: linux-kernel; +Cc: suspend2-devel On 2006-02-21, Nigel Cunningham <ncunningham@cyclades.com> wrote: > On Tuesday 21 February 2006 10:52, Andreas Happe wrote: > >> 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 eas= ier=20 to use, I'm more than willing to consider that. it's way too long ago to remember specifics, the system didn't resume after suspending. Swsusp worked just out of the box (sans dri support after resuming) without the need to apply a patch (which wasn't supplied as normal patch (if i remember correctly) but was used by starting a script)). I'm sorry that I didn't submit a proper bug report, but the alternative worked for me. You can't make it simpler except you get in included into mainline (even by making compromises). > 12 bytes per page is 3MB/1GB. If swsusp was to add support for > multiple swap partitions or writing to files, those requirement 20 > 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 ,20 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). This would take suspend2 a step closer to mainline.. you'll have a very honest 'Thank You' if that could happen.. andy ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: Re: [ 00/10] [Suspend2] Modules support.) 2006-02-21 12:59 ` Which is simpler? (Was " Andreas Happe @ 2006-02-22 0:33 ` Nigel Cunningham 0 siblings, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-22 0:33 UTC (permalink / raw) To: Andreas Happe; +Cc: linux-kernel, suspend2-devel [-- Attachment #1: Type: text/plain, Size: 2119 bytes --] Hi. On Tuesday 21 February 2006 22:59, Andreas Happe wrote: > On 2006-02-21, Nigel Cunningham <ncunningham@cyclades.com> wrote: > > On Tuesday 21 February 2006 10:52, Andreas Happe wrote: > >> 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 eas= ier=20 to use, I'm more than willing to consider that. > > it's way too long ago to remember specifics, the system didn't resume > after suspending. Swsusp worked just out of the box (sans dri support > after resuming) without the need to apply a patch (which wasn't supplied > as normal patch (if i remember correctly) but was used by starting a > script)). I'm sorry that I didn't submit a proper bug report, but the > alternative worked for me. Ok. That was when I provided multiple patches - they're all combined now. The script is still there, but just to make applying easier for newbies. > You can't make it simpler except you get in included into mainline (even > by making compromises). Agreed. > > 12 bytes per page is 3MB/1GB. If swsusp was to add support for > > multiple swap partitions or writing to files, those requirement 20 > > 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 ,20 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). > > This would take suspend2 a step closer to mainline.. you'll have a very > honest 'Thank You' if that could happen.. Well, we'll see what Rafael and I can work out. Regards, Nigel > andy > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 15:39 ` Olivier Galibert 2006-02-20 16:27 ` Andreas Happe @ 2006-02-20 16:41 ` Pavel Machek 2006-02-20 17:16 ` Rafael J. Wysocki 2 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 16:41 UTC (permalink / raw) To: Olivier Galibert, Rafael J. Wysocki, kernel list 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 15:39 ` Olivier Galibert 2006-02-20 16:27 ` Andreas Happe 2006-02-20 16:41 ` Which is simpler? (Was Re: [Suspend2-devel] " Pavel Machek @ 2006-02-20 17:16 ` Rafael J. Wysocki 2006-02-20 18:16 ` Olivier Galibert 2 siblings, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-20 17:16 UTC (permalink / raw) To: Olivier Galibert; +Cc: kernel list, Pavel Machek 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 17:16 ` Rafael J. Wysocki @ 2006-02-20 18:16 ` Olivier Galibert 2006-02-20 19:36 ` Pavel Machek 2006-02-20 20:24 ` Rafael J. Wysocki 0 siblings, 2 replies; 432+ messages in thread From: Olivier Galibert @ 2006-02-20 18:16 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: kernel list, Pavel Machek 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 18:16 ` Olivier Galibert @ 2006-02-20 19:36 ` Pavel Machek 2006-02-20 20:24 ` Rafael J. Wysocki 1 sibling, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 19:36 UTC (permalink / raw) To: Olivier Galibert, Rafael J. Wysocki, kernel list 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 18:16 ` Olivier Galibert 2006-02-20 19:36 ` Pavel Machek @ 2006-02-20 20:24 ` Rafael J. Wysocki 1 sibling, 0 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-20 20:24 UTC (permalink / raw) To: Olivier Galibert; +Cc: kernel list, Pavel Machek 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-20 9:39 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Matthias Hensler ` (3 preceding siblings ...) 2006-02-20 10:11 ` Lee Revell @ 2006-02-20 12:56 ` Pavel Machek 4 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-20 12:56 UTC (permalink / raw) To: Matthias Hensler; +Cc: Sebastian Kgler, kernel list, nigel, rjw 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-09 9:25 ` Pavel Machek 2006-02-09 9:26 ` Nigel Cunningham @ 2006-02-09 13:22 ` Rafael J. Wysocki 2006-02-09 22:16 ` Nigel Cunningham 1 sibling, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-09 13:22 UTC (permalink / raw) To: Pavel Machek; +Cc: Nigel Cunningham, suspend2-devel, Lee Revell, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-09 13:22 ` Rafael J. Wysocki @ 2006-02-09 22:16 ` Nigel Cunningham 2006-02-09 23:34 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-09 22:16 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: Pavel Machek, suspend2-devel, Lee Revell, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1910 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-09 22:16 ` Nigel Cunningham @ 2006-02-09 23:34 ` Pavel Machek 2006-02-10 0:08 ` Nigel Cunningham 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-09 23:34 UTC (permalink / raw) To: Nigel Cunningham Cc: Rafael J. Wysocki, suspend2-devel, Lee Revell, linux-kernel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-09 23:34 ` Pavel Machek @ 2006-02-10 0:08 ` Nigel Cunningham 2006-02-10 12:37 ` Rafael J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-10 0:08 UTC (permalink / raw) To: Pavel Machek; +Cc: Rafael J. Wysocki, suspend2-devel, Lee Revell, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2602 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-10 0:08 ` Nigel Cunningham @ 2006-02-10 12:37 ` Rafael J. Wysocki 2006-02-10 23:35 ` Flames over -- " Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-10 12:37 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Pavel Machek, suspend2-devel, Lee Revell, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-10 12:37 ` Rafael J. Wysocki @ 2006-02-10 23:35 ` Pavel Machek 2006-02-11 8:53 ` Kyle Moffett 2006-02-11 16:36 ` Jan Merka 0 siblings, 2 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-10 23:35 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Nigel Cunningham, suspend2-devel, Lee Revell, linux-kernel 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 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-10 23:35 ` Flames over -- " Pavel Machek @ 2006-02-11 8:53 ` Kyle Moffett 2006-02-11 17:06 ` hackmiester (Hunter Fuller) 2006-02-16 21:32 ` Pavel Machek 2006-02-11 16:36 ` Jan Merka 1 sibling, 2 replies; 432+ messages in thread From: Kyle Moffett @ 2006-02-11 8:53 UTC (permalink / raw) To: Pavel Machek Cc: Rafael J. Wysocki, Nigel Cunningham, suspend2-devel, Lee Revell, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-11 8:53 ` Kyle Moffett @ 2006-02-11 17:06 ` hackmiester (Hunter Fuller) 2006-02-16 21:32 ` Pavel Machek 1 sibling, 0 replies; 432+ messages in thread From: hackmiester (Hunter Fuller) @ 2006-02-11 17:06 UTC (permalink / raw) To: Kyle Moffett, linux-kernel 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ > > -- --hackmiester Walk a mile in my shoes and you will be a mile away in a new pair of shoes. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-11 8:53 ` Kyle Moffett 2006-02-11 17:06 ` hackmiester (Hunter Fuller) @ 2006-02-16 21:32 ` Pavel Machek 1 sibling, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-16 21:32 UTC (permalink / raw) To: Kyle Moffett Cc: Pavel Machek, Rafael J. Wysocki, Nigel Cunningham, suspend2-devel, Lee Revell, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-10 23:35 ` Flames over -- " Pavel Machek 2006-02-11 8:53 ` Kyle Moffett @ 2006-02-11 16:36 ` Jan Merka 2006-02-11 22:18 ` Theodoros V. Kalamatianos 2006-02-11 23:35 ` Kyle Moffett 1 sibling, 2 replies; 432+ messages in thread From: Jan Merka @ 2006-02-11 16:36 UTC (permalink / raw) To: suspend2-devel; +Cc: Pavel Machek, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-11 16:36 ` Jan Merka @ 2006-02-11 22:18 ` Theodoros V. Kalamatianos 2006-02-11 23:35 ` Kyle Moffett 1 sibling, 0 replies; 432+ messages in thread From: Theodoros V. Kalamatianos @ 2006-02-11 22:18 UTC (permalink / raw) To: Jan Merka; +Cc: suspend2-devel, linux-kernel, Pavel Machek 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... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-11 16:36 ` Jan Merka 2006-02-11 22:18 ` Theodoros V. Kalamatianos @ 2006-02-11 23:35 ` Kyle Moffett 2006-02-12 8:51 ` Alon Bar-Lev 1 sibling, 1 reply; 432+ messages in thread From: Kyle Moffett @ 2006-02-11 23:35 UTC (permalink / raw) To: Jan Merka; +Cc: suspend2-devel, Pavel Machek, linux-kernel 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------ ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-11 23:35 ` Kyle Moffett @ 2006-02-12 8:51 ` Alon Bar-Lev 2006-02-12 11:11 ` Kyle Moffett 2006-02-12 16:42 ` hackmiester / Hunter Fuller 0 siblings, 2 replies; 432+ messages in thread From: Alon Bar-Lev @ 2006-02-12 8:51 UTC (permalink / raw) To: Kyle Moffett; +Cc: Jan Merka, Pavel Machek, suspend2-devel, linux-kernel 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-12 8:51 ` Alon Bar-Lev @ 2006-02-12 11:11 ` Kyle Moffett 2006-02-12 12:06 ` Alon Bar-Lev 2006-02-12 16:42 ` hackmiester / Hunter Fuller 1 sibling, 1 reply; 432+ messages in thread From: Kyle Moffett @ 2006-02-12 11:11 UTC (permalink / raw) To: Alon Bar-Lev; +Cc: Jan Merka, Pavel Machek, suspend2-devel, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-12 11:11 ` Kyle Moffett @ 2006-02-12 12:06 ` Alon Bar-Lev 2006-02-12 16:32 ` Kyle Moffett 2006-02-16 21:53 ` Pavel Machek 0 siblings, 2 replies; 432+ messages in thread From: Alon Bar-Lev @ 2006-02-12 12:06 UTC (permalink / raw) To: Kyle Moffett; +Cc: Jan Merka, Pavel Machek, suspend2-devel, linux-kernel 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-12 12:06 ` Alon Bar-Lev @ 2006-02-12 16:32 ` Kyle Moffett 2006-02-12 16:56 ` Valdis.Kletnieks 2006-02-13 12:11 ` Johannes Berg 2006-02-16 21:53 ` Pavel Machek 1 sibling, 2 replies; 432+ messages in thread From: Kyle Moffett @ 2006-02-12 16:32 UTC (permalink / raw) To: Alon Bar-Lev; +Cc: Jan Merka, Pavel Machek, suspend2-devel, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-12 16:32 ` Kyle Moffett @ 2006-02-12 16:56 ` Valdis.Kletnieks 2006-02-12 18:28 ` Kyle Moffett 2006-02-13 12:11 ` Johannes Berg 1 sibling, 1 reply; 432+ messages in thread From: Valdis.Kletnieks @ 2006-02-12 16:56 UTC (permalink / raw) To: Kyle Moffett Cc: Alon Bar-Lev, Jan Merka, Pavel Machek, suspend2-devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 775 bytes --] 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. [-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-12 16:56 ` Valdis.Kletnieks @ 2006-02-12 18:28 ` Kyle Moffett 2006-02-13 12:12 ` Johannes Berg 0 siblings, 1 reply; 432+ messages in thread From: Kyle Moffett @ 2006-02-12 18:28 UTC (permalink / raw) To: Valdis.Kletnieks Cc: Alon Bar-Lev, Jan Merka, Pavel Machek, suspend2-devel, linux-kernel On Feb 12, 2006, at 11:56, Valdis.Kletnieks@vt.edu 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-12 18:28 ` Kyle Moffett @ 2006-02-13 12:12 ` Johannes Berg 0 siblings, 0 replies; 432+ messages in thread From: Johannes Berg @ 2006-02-13 12:12 UTC (permalink / raw) To: Kyle Moffett; +Cc: Valdis.Kletnieks, suspend2-devel, Pavel Machek, linux-kernel [-- Attachment #1: Type: text/plain, Size: 900 bytes --] 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 [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 793 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-12 16:32 ` Kyle Moffett 2006-02-12 16:56 ` Valdis.Kletnieks @ 2006-02-13 12:11 ` Johannes Berg 1 sibling, 0 replies; 432+ messages in thread From: Johannes Berg @ 2006-02-13 12:11 UTC (permalink / raw) To: Kyle Moffett; +Cc: Alon Bar-Lev, suspend2-devel, Pavel Machek, linux-kernel [-- Attachment #1: Type: text/plain, Size: 310 bytes --] 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 [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 793 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-12 12:06 ` Alon Bar-Lev 2006-02-12 16:32 ` Kyle Moffett @ 2006-02-16 21:53 ` Pavel Machek 2006-02-20 6:51 ` Nigel Cunningham 1 sibling, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-16 21:53 UTC (permalink / raw) To: Alon Bar-Lev Cc: Kyle Moffett, Jan Merka, Pavel Machek, suspend2-devel, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-16 21:53 ` Pavel Machek @ 2006-02-20 6:51 ` Nigel Cunningham 0 siblings, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-20 6:51 UTC (permalink / raw) To: Pavel Machek Cc: Alon Bar-Lev, Kyle Moffett, Jan Merka, Pavel Machek, suspend2-devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 852 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Flames over -- Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-12 8:51 ` Alon Bar-Lev 2006-02-12 11:11 ` Kyle Moffett @ 2006-02-12 16:42 ` hackmiester / Hunter Fuller 1 sibling, 0 replies; 432+ messages in thread From: hackmiester / Hunter Fuller @ 2006-02-12 16:42 UTC (permalink / raw) To: Alon Bar-Lev, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2262 bytes --] 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 majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- --hackmiester If you can read this, you don't need glasses. [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 23:02 ` Pavel Machek 2006-02-07 23:11 ` Nigel Cunningham @ 2006-02-07 23:27 ` Rafael J. Wysocki 2006-02-07 23:50 ` Pavel Machek 2006-02-07 23:38 ` Lee Revell 2006-02-07 23:50 ` Jim Crilly 3 siblings, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-07 23:27 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Lee Revell, Jim Crilly, suspend2-devel, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 23:27 ` Rafael J. Wysocki @ 2006-02-07 23:50 ` Pavel Machek 2006-02-08 0:16 ` Rafael J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-07 23:50 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Nigel Cunningham, Lee Revell, Jim Crilly, suspend2-devel, linux-kernel > > > 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 <pavel@suse.cz> 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 23:50 ` Pavel Machek @ 2006-02-08 0:16 ` Rafael J. Wysocki 2006-02-08 8:28 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-08 0:16 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Lee Revell, Jim Crilly, suspend2-devel, linux-kernel 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 <pavel@suse.cz> > > > 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-08 0:16 ` Rafael J. Wysocki @ 2006-02-08 8:28 ` Pavel Machek 2006-02-08 9:43 ` Rafael J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-08 8:28 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Nigel Cunningham, Lee Revell, Jim Crilly, suspend2-devel, linux-kernel Hi! > > Suspend-to-disk HOWTO > > ~~~~~~~~~~~~~~~~~~~~ > > Copyright (C) 2006 Pavel Machek <pavel@suse.cz> > > > > > > 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-08 8:28 ` Pavel Machek @ 2006-02-08 9:43 ` Rafael J. Wysocki 0 siblings, 0 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-08 9:43 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Lee Revell, Jim Crilly, suspend2-devel, linux-kernel Hi, On Wednesday 08 February 2006 09:28, Pavel Machek wrote: > > > Suspend-to-disk HOWTO > > > ~~~~~~~~~~~~~~~~~~~~ > > > Copyright (C) 2006 Pavel Machek <pavel@suse.cz> > > > > > > > > > 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 23:02 ` Pavel Machek 2006-02-07 23:11 ` Nigel Cunningham 2006-02-07 23:27 ` Rafael J. Wysocki @ 2006-02-07 23:38 ` Lee Revell 2006-02-07 23:50 ` Jim Crilly 3 siblings, 0 replies; 432+ messages in thread From: Lee Revell @ 2006-02-07 23:38 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Jim Crilly, Rafael J. Wysocki, suspend2-devel, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 23:02 ` Pavel Machek ` (2 preceding siblings ...) 2006-02-07 23:38 ` Lee Revell @ 2006-02-07 23:50 ` Jim Crilly 3 siblings, 0 replies; 432+ messages in thread From: Jim Crilly @ 2006-02-07 23:50 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Lee Revell, Rafael J. Wysocki, suspend2-devel, linux-kernel 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 3:01 ` Jim Crilly 2006-02-07 3:03 ` Nigel Cunningham 2006-02-07 3:13 ` Lee Revell @ 2006-02-07 3:17 ` Lee Revell 2006-02-07 3:32 ` Nigel Cunningham 2006-02-07 9:33 ` Pavel Machek 2 siblings, 2 replies; 432+ messages in thread From: Lee Revell @ 2006-02-07 3:17 UTC (permalink / raw) To: Jim Crilly Cc: Pavel Machek, Rafael J. Wysocki, Nigel Cunningham, suspend2-devel, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 3:17 ` Lee Revell @ 2006-02-07 3:32 ` Nigel Cunningham 2006-02-07 4:10 ` Bojan Smojver 2006-02-07 11:01 ` Henrik Brix Andersen 2006-02-07 9:33 ` Pavel Machek 1 sibling, 2 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-07 3:32 UTC (permalink / raw) To: Lee Revell Cc: Jim Crilly, Pavel Machek, Rafael J. Wysocki, suspend2-devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 2172 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 3:32 ` Nigel Cunningham @ 2006-02-07 4:10 ` Bojan Smojver 2006-02-07 11:01 ` Henrik Brix Andersen 1 sibling, 0 replies; 432+ messages in thread From: Bojan Smojver @ 2006-02-07 4:10 UTC (permalink / raw) To: Nigel Cunningham Cc: Lee Revell, Rafael J. Wysocki, suspend2-devel, Pavel Machek, linux-kernel Quoting Nigel Cunningham <nigel@suspend2.net>: > 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 3:32 ` Nigel Cunningham 2006-02-07 4:10 ` Bojan Smojver @ 2006-02-07 11:01 ` Henrik Brix Andersen 1 sibling, 0 replies; 432+ messages in thread From: Henrik Brix Andersen @ 2006-02-07 11:01 UTC (permalink / raw) To: Nigel Cunningham Cc: Lee Revell, Rafael J. Wysocki, suspend2-devel, Pavel Machek, linux-kernel [-- Attachment #1: Type: text/plain, Size: 977 bytes --] 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 <brix@gentoo.org> Gentoo Metadistribution | Mobile computing herd [-- Attachment #2: Type: application/pgp-signature, Size: 211 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 3:17 ` Lee Revell 2006-02-07 3:32 ` Nigel Cunningham @ 2006-02-07 9:33 ` Pavel Machek 2006-02-07 9:36 ` Nigel Cunningham ` (2 more replies) 1 sibling, 3 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-07 9:33 UTC (permalink / raw) To: Lee Revell Cc: Jim Crilly, Rafael J. Wysocki, Nigel Cunningham, suspend2-devel, linux-kernel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 9:33 ` Pavel Machek @ 2006-02-07 9:36 ` Nigel Cunningham 2006-02-07 22:57 ` Pavel Machek 2006-02-07 10:17 ` Nigel Cunningham 2006-02-07 15:47 ` Lee Revell 2 siblings, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-07 9:36 UTC (permalink / raw) To: Pavel Machek Cc: Lee Revell, Jim Crilly, Rafael J. Wysocki, suspend2-devel, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1130 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 9:36 ` Nigel Cunningham @ 2006-02-07 22:57 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-07 22:57 UTC (permalink / raw) To: Nigel Cunningham Cc: Lee Revell, Jim Crilly, Rafael J. Wysocki, suspend2-devel, linux-kernel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 9:33 ` Pavel Machek 2006-02-07 9:36 ` Nigel Cunningham @ 2006-02-07 10:17 ` Nigel Cunningham 2006-02-07 15:47 ` Lee Revell 2 siblings, 0 replies; 432+ messages in thread From: Nigel Cunningham @ 2006-02-07 10:17 UTC (permalink / raw) To: suspend2-devel; +Cc: Pavel Machek, Lee Revell, Rafael J. Wysocki, linux-kernel [-- Attachment #1: Type: text/plain, Size: 1118 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 9:33 ` Pavel Machek 2006-02-07 9:36 ` Nigel Cunningham 2006-02-07 10:17 ` Nigel Cunningham @ 2006-02-07 15:47 ` Lee Revell 2006-02-07 15:49 ` Pavel Machek 2 siblings, 1 reply; 432+ messages in thread From: Lee Revell @ 2006-02-07 15:47 UTC (permalink / raw) To: Pavel Machek Cc: Jim Crilly, Rafael J. Wysocki, Nigel Cunningham, suspend2-devel, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 15:47 ` Lee Revell @ 2006-02-07 15:49 ` Pavel Machek 0 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-07 15:49 UTC (permalink / raw) To: Lee Revell Cc: Jim Crilly, Rafael J. Wysocki, Nigel Cunningham, suspend2-devel, linux-kernel 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 4:02 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Nigel Cunningham 2006-02-06 4:34 ` Lee Revell @ 2006-02-06 10:59 ` Pavel Machek 2006-02-06 12:13 ` Nigel Cunningham 2006-02-06 14:49 ` Mark Lord 1 sibling, 2 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-06 10:59 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Rafael Wysocki, linux-kernel, Suspend2 Devel List 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 10:59 ` Pavel Machek @ 2006-02-06 12:13 ` Nigel Cunningham 2006-02-06 12:40 ` Pavel Machek 2006-02-06 14:49 ` Mark Lord 1 sibling, 1 reply; 432+ messages in thread From: Nigel Cunningham @ 2006-02-06 12:13 UTC (permalink / raw) To: Pavel Machek; +Cc: Rafael Wysocki, linux-kernel, Suspend2 Devel List [-- Attachment #1: Type: text/plain, Size: 9833 bytes --] 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 [-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 12:13 ` Nigel Cunningham @ 2006-02-06 12:40 ` Pavel Machek 2006-02-06 12:50 ` Jens Axboe 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-06 12:40 UTC (permalink / raw) To: Nigel Cunningham; +Cc: Rafael Wysocki, linux-kernel, Suspend2 Devel List 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 12:40 ` Pavel Machek @ 2006-02-06 12:50 ` Jens Axboe 2006-02-06 12:52 ` Pavel Machek 0 siblings, 1 reply; 432+ messages in thread From: Jens Axboe @ 2006-02-06 12:50 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Rafael Wysocki, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 12:50 ` Jens Axboe @ 2006-02-06 12:52 ` Pavel Machek 2006-02-06 13:04 ` Jens Axboe 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-06 12:52 UTC (permalink / raw) To: Jens Axboe Cc: Nigel Cunningham, Rafael Wysocki, linux-kernel, Suspend2 Devel List 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 12:52 ` Pavel Machek @ 2006-02-06 13:04 ` Jens Axboe 2006-02-06 13:45 ` Rafael J. Wysocki 2006-02-06 14:24 ` Pavel Machek 0 siblings, 2 replies; 432+ messages in thread From: Jens Axboe @ 2006-02-06 13:04 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Rafael Wysocki, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 13:04 ` Jens Axboe @ 2006-02-06 13:45 ` Rafael J. Wysocki 2006-02-06 13:59 ` Jens Axboe 2006-02-06 14:24 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-06 13:45 UTC (permalink / raw) To: Jens Axboe Cc: Pavel Machek, Nigel Cunningham, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 13:45 ` Rafael J. Wysocki @ 2006-02-06 13:59 ` Jens Axboe 0 siblings, 0 replies; 432+ messages in thread From: Jens Axboe @ 2006-02-06 13:59 UTC (permalink / raw) To: Rafael J. Wysocki Cc: Pavel Machek, Nigel Cunningham, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 13:04 ` Jens Axboe 2006-02-06 13:45 ` Rafael J. Wysocki @ 2006-02-06 14:24 ` Pavel Machek 1 sibling, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-06 14:24 UTC (permalink / raw) To: Jens Axboe Cc: Nigel Cunningham, Rafael Wysocki, linux-kernel, Suspend2 Devel List 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 10:59 ` Pavel Machek 2006-02-06 12:13 ` Nigel Cunningham @ 2006-02-06 14:49 ` Mark Lord 2006-02-06 14:52 ` Pavel Machek 1 sibling, 1 reply; 432+ messages in thread From: Mark Lord @ 2006-02-06 14:49 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Rafael Wysocki, linux-kernel, Suspend2 Devel List >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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 14:49 ` Mark Lord @ 2006-02-06 14:52 ` Pavel Machek 2006-02-07 0:20 ` Mark Lord 0 siblings, 1 reply; 432+ messages in thread From: Pavel Machek @ 2006-02-06 14:52 UTC (permalink / raw) To: Mark Lord Cc: Nigel Cunningham, Rafael Wysocki, linux-kernel, Suspend2 Devel List 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 (www.sf.net/projects/suspend) wanted... ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-06 14:52 ` Pavel Machek @ 2006-02-07 0:20 ` Mark Lord 2006-02-07 0:23 ` Randy.Dunlap 0 siblings, 1 reply; 432+ messages in thread From: Mark Lord @ 2006-02-07 0:20 UTC (permalink / raw) To: Pavel Machek Cc: Nigel Cunningham, Rafael Wysocki, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-07 0:20 ` Mark Lord @ 2006-02-07 0:23 ` Randy.Dunlap 0 siblings, 0 replies; 432+ messages in thread From: Randy.Dunlap @ 2006-02-07 0:23 UTC (permalink / raw) To: Mark Lord Cc: Pavel Machek, Nigel Cunningham, Rafael Wysocki, linux-kernel, Suspend2 Devel List 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
[parent not found: <200602100007.10233.rjw@sisk.pl>]
[parent not found: <20060209231459.GA3389@elf.ucw.cz>]
[parent not found: <200602100035.04969.rjw@sisk.pl>]
[parent not found: <20060210002406.GF8154@blackham.com.au>]
[parent not found: <20060210003533.GJ3389@elf.ucw.cz>]
* Re: chroot in swsusp userland interface (was: Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) [not found] ` <20060210003533.GJ3389@elf.ucw.cz> @ 2006-02-11 8:55 ` Bernard Blackham 2006-02-11 9:50 ` Rafael J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Bernard Blackham @ 2006-02-11 8:55 UTC (permalink / raw) To: Pavel Machek Cc: Rafael J. Wysocki, Nigel Cunningham, Userland Suspend Devel, linux-kernel 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> ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: chroot in swsusp userland interface (was: Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-11 8:55 ` chroot in swsusp userland interface (was: " Bernard Blackham @ 2006-02-11 9:50 ` Rafael J. Wysocki 0 siblings, 0 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-11 9:50 UTC (permalink / raw) To: Bernard Blackham Cc: Pavel Machek, Nigel Cunningham, Userland Suspend Devel, linux-kernel 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 21:27 ` Andrew Morton ` (2 preceding siblings ...) 2006-02-02 23:18 ` Nigel Cunningham @ 2006-02-03 11:21 ` Pavel Machek 2006-02-04 0:46 ` Barry K. Nathan 2006-02-11 13:42 ` Eric W. Biederman 5 siblings, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-03 11:21 UTC (permalink / raw) To: Andrew Morton; +Cc: nigel, torvalds, linux-kernel On Čt 02-02-06 13:27:08, Andrew Morton wrote: > Pavel Machek <pavel@ucw.cz> 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 21:27 ` Andrew Morton ` (3 preceding siblings ...) 2006-02-03 11:21 ` [ 00/10] [Suspend2] Modules support Pavel Machek @ 2006-02-04 0:46 ` Barry K. Nathan 2006-02-04 11:02 ` Rafael J. Wysocki 2006-02-11 13:42 ` Eric W. Biederman 5 siblings, 1 reply; 432+ messages in thread From: Barry K. Nathan @ 2006-02-04 0:46 UTC (permalink / raw) To: Andrew Morton; +Cc: Pavel Machek, nigel, torvalds, linux-kernel On 2/2/06, Andrew Morton <akpm@osdl.org> 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 <barryn@pobox.com> ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-04 0:46 ` Barry K. Nathan @ 2006-02-04 11:02 ` Rafael J. Wysocki 0 siblings, 0 replies; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-04 11:02 UTC (permalink / raw) To: Barry K. Nathan Cc: Andrew Morton, Pavel Machek, nigel, torvalds, linux-kernel On Saturday 04 February 2006 01:46, Barry K. Nathan wrote: > On 2/2/06, Andrew Morton <akpm@osdl.org> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 21:27 ` Andrew Morton ` (4 preceding siblings ...) 2006-02-04 0:46 ` Barry K. Nathan @ 2006-02-11 13:42 ` Eric W. Biederman 2006-02-11 15:19 ` Randy.Dunlap 5 siblings, 1 reply; 432+ messages in thread From: Eric W. Biederman @ 2006-02-11 13:42 UTC (permalink / raw) To: Andrew Morton; +Cc: Pavel Machek, nigel, torvalds, linux-kernel Andrew Morton <akpm@osdl.org> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-11 13:42 ` Eric W. Biederman @ 2006-02-11 15:19 ` Randy.Dunlap 0 siblings, 0 replies; 432+ messages in thread From: Randy.Dunlap @ 2006-02-11 15:19 UTC (permalink / raw) To: Eric W. Biederman; +Cc: akpm, pavel, nigel, torvalds, linux-kernel On Sat, 11 Feb 2006 06:42:12 -0700 Eric W. Biederman wrote: > Andrew Morton <akpm@osdl.org> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: [ 00/10] [Suspend2] Modules support. 2006-02-02 10:38 ` Nigel Cunningham 2006-02-02 10:47 ` Pavel Machek @ 2006-02-02 10:48 ` Pavel Machek 1 sibling, 0 replies; 432+ messages in thread From: Pavel Machek @ 2006-02-02 10:48 UTC (permalink / raw) To: Nigel Cunningham; +Cc: linux-kernel 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! ^ permalink raw reply [flat|nested] 432+ messages in thread
[parent not found: <5BoER-4GL-3@gated-at.bofh.it>]
[parent not found: <5DJOW-7ll-9@gated-at.bofh.it>]
[parent not found: <5DK8h-7YA-13@gated-at.bofh.it>]
[parent not found: <5DKrG-8nS-13@gated-at.bofh.it>]
[parent not found: <5DKUI-1Dm-21@gated-at.bofh.it>]
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) [not found] ` <5DKUI-1Dm-21@gated-at.bofh.it> @ 2006-02-08 13:23 ` Bodo Eggert 2006-02-08 14:23 ` Rafael J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Bodo Eggert @ 2006-02-08 13:23 UTC (permalink / raw) To: Pavel Machek, Rafael J. Wysocki, Nigel Cunningham, Lee Revell, Jim Crilly, suspend2-devel, linux-kernel There are some questions I have while looking at this HOWTO, which I think should be answered there: Pavel Machek <pavel@ucw.cz> 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. ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-08 13:23 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Bodo Eggert @ 2006-02-08 14:23 ` Rafael J. Wysocki 2006-02-08 23:20 ` R. J. Wysocki 0 siblings, 1 reply; 432+ messages in thread From: Rafael J. Wysocki @ 2006-02-08 14:23 UTC (permalink / raw) To: 7eggert Cc: Pavel Machek, Nigel Cunningham, Lee Revell, Jim Crilly, suspend2-devel, linux-kernel 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 <pavel@ucw.cz> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
* Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) 2006-02-08 14:23 ` Rafael J. Wysocki @ 2006-02-08 23:20 ` R. J. Wysocki 0 siblings, 0 replies; 432+ messages in thread From: R. J. Wysocki @ 2006-02-08 23:20 UTC (permalink / raw) To: 7eggert Cc: Pavel Machek, Nigel Cunningham, Lee Revell, Jim Crilly, suspend2-devel, linux-kernel 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 <pavel@ucw.cz> 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 ^ permalink raw reply [flat|nested] 432+ messages in thread
end of thread, other threads:[~2006-02-27 0:14 UTC | newest] Thread overview: 432+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-02-01 11:37 [ 00/10] [Suspend2] Modules support Nigel Cunningham 2006-02-01 11:37 ` [ 01/10] [Suspend2] kernel/power/modules.h Nigel Cunningham 2006-02-01 12:32 ` Pekka Enberg 2006-02-01 12:45 ` Nigel Cunningham 2006-02-01 13:01 ` Pekka Enberg 2006-02-01 21:30 ` Nigel Cunningham 2006-02-01 21:45 ` Pekka Enberg 2006-02-01 22:55 ` Nigel Cunningham 2006-02-02 8:31 ` Rafael J. Wysocki 2006-02-02 9:22 ` Nigel Cunningham 2006-02-02 10:16 ` Pavel Machek 2006-02-02 10:29 ` Nigel Cunningham 2006-02-02 10:39 ` Pavel Machek 2006-02-02 11:20 ` Nigel Cunningham 2006-02-02 11:40 ` Pavel Machek 2006-02-02 13:34 ` Rafael J. Wysocki 2006-02-02 21:27 ` Nigel Cunningham 2006-02-02 23:12 ` Rafael J. Wysocki 2006-02-02 9:38 ` Pavel Machek 2006-02-02 10:30 ` Nigel Cunningham 2006-02-02 12:53 ` Rafael J. Wysocki 2006-02-02 21:27 ` Nigel Cunningham 2006-02-02 22:10 ` Rafael J. Wysocki 2006-02-03 0:20 ` Nigel Cunningham 2006-02-03 8:57 ` Rafael J. Wysocki 2006-02-03 11:47 ` Nigel Cunningham 2006-02-03 22:52 ` Pavel Machek 2006-02-03 13:16 ` Pavel Machek 2006-02-03 13:41 ` Nigel Cunningham 2006-02-03 23:45 ` Pavel Machek 2006-02-02 10:06 ` Pavel Machek 2006-02-02 10:57 ` Pekka Enberg 2006-02-02 11:02 ` Pavel Machek 2006-02-02 11:16 ` Pekka Enberg 2006-02-02 11:39 ` Pavel Machek 2006-02-02 11:35 ` Nigel Cunningham 2006-02-02 11:44 ` Nigel Cunningham 2006-02-02 12:48 ` Pekka J Enberg 2006-02-02 21:27 ` Nigel Cunningham 2006-02-01 17:12 ` [ 01/10] [Suspend2] kernel/power/modules.h' Randy.Dunlap 2006-02-01 21:31 ` Nigel Cunningham 2006-02-02 11:35 ` Nigel Cunningham 2006-02-01 11:37 ` [ 02/10] [Suspend2] Module (de)registration Nigel Cunningham 2006-02-01 12:37 ` Pekka Enberg 2006-02-01 12:47 ` Nigel Cunningham 2006-02-02 9:54 ` Pavel Machek 2006-02-02 10:33 ` Nigel Cunningham 2006-02-01 11:37 ` [ 03/10] [Suspend2] Move module to the tail of lists Nigel Cunningham 2006-02-01 11:37 ` [ 04/10] [Suspend2] Module initialise/cleanup Nigel Cunningham 2006-02-01 11:37 ` [ 05/10] [Suspend2] Get next module Nigel Cunningham 2006-02-01 11:37 ` [ 06/10] [Suspend2] Get/put module reference Nigel Cunningham 2006-02-01 11:37 ` [ 07/10] [Suspend2] Header storage for modules Nigel Cunningham 2006-02-01 11:37 ` [ 08/10] [Suspend2] Find a module given its name Nigel Cunningham 2006-02-01 11:37 ` [ 09/10] [Suspend2] Append module debug info to a buffer Nigel Cunningham 2006-02-01 11:37 ` [ 10/10] [Suspend2] Memory needed for modules Nigel Cunningham 2006-02-01 12:38 ` [ 00/10] [Suspend2] Modules support Pekka Enberg 2006-02-01 12:49 ` Nigel Cunningham 2006-02-02 10:05 ` Pavel Machek 2006-02-02 10:38 ` Nigel Cunningham 2006-02-02 10:47 ` Pavel Machek 2006-02-02 11:31 ` Nigel Cunningham 2006-02-02 11:44 ` Pekka Enberg 2006-02-02 12:28 ` Nigel Cunningham 2006-02-02 13:26 ` Pekka J Enberg 2006-02-02 15:14 ` Pavel Machek 2006-02-02 15:43 ` Olivier Galibert 2006-02-02 20:25 ` Pavel Machek 2006-02-02 20:31 ` Dave Jones 2006-02-02 20:51 ` Pavel Machek 2006-02-03 1:18 ` Olivier Galibert 2006-02-03 10:41 ` Pavel Machek 2006-02-03 14:29 ` Olivier Galibert 2006-02-03 17:24 ` Rafael J. Wysocki 2006-02-03 18:30 ` Olivier Galibert 2006-02-03 21:08 ` Rafael J. Wysocki 2006-02-04 0:26 ` Olivier Galibert 2006-02-04 0:44 ` Pavel Machek 2006-02-03 22:36 ` Pavel Machek 2006-02-02 11:59 ` Pavel Machek 2006-02-02 12:14 ` Nigel Cunningham 2006-02-02 15:23 ` Pavel Machek 2006-02-02 21:27 ` Andrew Morton 2006-02-02 21:34 ` Lee Revell 2006-02-02 22:23 ` Andrew Morton 2006-02-02 22:29 ` Lee Revell 2006-02-02 22:48 ` Andrew Morton 2006-02-03 1:48 ` Olivier Galibert 2006-02-03 6:49 ` Nigel Cunningham 2006-02-03 10:58 ` Pavel Machek 2006-02-03 9:49 ` Matthew Garrett 2006-02-03 10:23 ` Andrew Morton 2006-02-03 10:43 ` Matthew Garrett 2006-02-03 15:53 ` Dave Jones 2006-02-03 11:08 ` Pavel Machek 2006-02-03 10:51 ` Pavel Machek [not found] ` <58cb370e0602030322u4c2c9f9bm21a38be6d35d2ea6@mail.gmail.com> 2006-02-03 11:35 ` Pavel Machek 2006-02-03 13:46 ` Bartlomiej Zolnierkiewicz 2006-02-03 14:10 ` Matthew Garrett 2006-02-03 14:32 ` Bartlomiej Zolnierkiewicz 2006-02-03 16:34 ` Randy.Dunlap 2006-02-03 16:44 ` Bartlomiej Zolnierkiewicz 2006-02-03 16:57 ` Randy.Dunlap 2006-02-03 18:46 ` Bartlomiej Zolnierkiewicz 2006-02-02 22:54 ` Nigel Cunningham 2006-02-02 23:10 ` Rafael J. Wysocki 2006-02-02 23:18 ` Nigel Cunningham 2006-02-03 1:00 ` [Suspend2-devel] " Bojan Smojver 2006-02-03 1:18 ` Andrew Morton 2006-02-03 1:32 ` Nigel Cunningham 2006-02-03 1:42 ` Bojan Smojver 2006-02-03 9:18 ` Rafael J. Wysocki [not found] ` <1138962557.18190.18.camel@coyote.rexursive.com> [not found] ` <200602031254.37335.rjw@sisk.pl> 2006-02-03 23:53 ` Bojan Smojver 2006-02-03 11:49 ` Pavel Machek 2006-02-03 23:43 ` Bojan Smojver 2006-02-03 23:55 ` Pavel Machek 2006-02-04 0:05 ` Bojan Smojver [not found] ` <20060204005310.GG3291@elf.ucw.cz> 2006-02-04 1:13 ` Bojan Smojver 2006-02-04 8:53 ` Pavel Machek 2006-02-04 10:08 ` Nigel Cunningham 2006-02-05 22:07 ` Pavel Machek 2006-02-04 13:59 ` Harald Arnesen 2006-02-05 3:06 ` Bojan Smojver 2006-02-05 2:59 ` Bojan Smojver 2006-02-04 0:36 ` Olivier Galibert 2006-02-04 0:49 ` Pavel Machek 2006-02-04 1:08 ` Olivier Galibert 2006-02-04 1:23 ` Pavel Machek 2006-02-04 2:18 ` Bojan Smojver 2006-02-04 13:51 ` chroot in swsusp userland interface (was: Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Rafael J. Wysocki 2006-02-04 19:21 ` Pavel Machek 2006-02-04 19:57 ` Rafael J. Wysocki 2006-02-04 20:15 ` Pavel Machek 2006-02-04 20:45 ` Rafael J. Wysocki 2006-02-06 9:05 ` Bernard Blackham 2006-02-05 23:02 ` Nigel Cunningham 2006-02-06 15:13 ` Rafael J. Wysocki 2006-02-08 23:51 ` Nigel Cunningham 2006-02-03 11:44 ` [ 00/10] [Suspend2] Modules support Pavel Machek 2006-02-03 23:42 ` [Suspend2-devel] " Bojan Smojver 2006-02-04 1:20 ` Nigel Cunningham 2006-02-04 9:01 ` Pavel Machek 2006-02-04 9:54 ` Nigel Cunningham 2006-02-04 10:58 ` Rafael J. Wysocki 2006-02-04 11:08 ` Nigel Cunningham 2006-02-04 11:38 ` Rafael J. Wysocki 2006-02-04 11:41 ` Nigel Cunningham 2006-02-04 13:09 ` Rafael J. Wysocki 2006-02-04 17:18 ` Rafael J. Wysocki 2006-02-05 23:43 ` [Suspend2-devel] " Nigel Cunningham 2006-02-05 23:56 ` Rafael J. Wysocki 2006-02-06 21:07 ` Jim Crilly 2006-02-07 0:16 ` Nigel Cunningham 2006-02-07 15:16 ` Rafael J. Wysocki 2006-02-04 19:10 ` Pavel Machek 2006-02-05 23:44 ` [Suspend2-devel] " Nigel Cunningham 2006-02-06 10:13 ` Pavel Machek 2006-02-04 19:29 ` Pavel Machek 2006-02-06 4:02 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Nigel Cunningham 2006-02-06 4:34 ` Lee Revell 2006-02-06 5:43 ` Nigel Cunningham 2006-02-06 18:48 ` Lee Revell 2006-02-06 20:25 ` Nigel Cunningham 2006-02-06 23:51 ` Rafael J. Wysocki 2006-02-06 23:57 ` Nigel Cunningham 2006-02-07 0:29 ` Pavel Machek 2006-02-07 0:43 ` Nigel Cunningham 2006-02-07 0:31 ` Bojan Smojver 2006-02-07 0:44 ` Pavel Machek 2006-02-07 1:05 ` Nigel Cunningham 2006-02-07 2:20 ` Bojan Smojver 2006-02-07 9:23 ` Pavel Machek 2006-02-07 10:06 ` Nigel Cunningham 2006-02-07 23:03 ` Pavel Machek 2006-02-07 15:09 ` Rafael J. Wysocki 2006-02-07 22:13 ` Nigel Cunningham 2006-02-07 23:05 ` Pavel Machek 2006-02-07 23:13 ` Nigel Cunningham 2006-02-07 23:17 ` Nigel Cunningham 2006-02-07 23:36 ` Pavel Machek 2006-02-07 23:50 ` Rafael J. Wysocki 2006-02-07 0:37 ` Jim Crilly 2006-02-07 0:46 ` Pavel Machek 2006-02-07 0:59 ` Jim Crilly 2006-02-07 1:19 ` Lee Revell 2006-02-07 3:01 ` Jim Crilly 2006-02-07 3:03 ` Nigel Cunningham 2006-02-07 3:13 ` Lee Revell 2006-02-07 3:26 ` Nigel Cunningham 2006-02-07 9:37 ` Pavel Machek 2006-02-07 9:40 ` Nigel Cunningham 2006-02-07 23:02 ` Pavel Machek 2006-02-07 23:11 ` Nigel Cunningham 2006-02-08 6:59 ` Rafael J. Wysocki 2006-02-08 7:33 ` Nigel Cunningham 2006-02-08 8:15 ` Pavel Machek 2006-02-08 10:03 ` Rafael J. Wysocki 2006-02-08 12:08 ` Nigel Cunningham 2006-02-09 0:06 ` Pavel Machek 2006-02-09 2:45 ` Nigel Cunningham 2006-02-09 9:25 ` Pavel Machek 2006-02-09 9:26 ` Nigel Cunningham 2006-02-09 23:24 ` Pavel Machek 2006-02-11 0:16 ` Sebastian Kügler 2006-02-11 1:12 ` Pavel Machek 2006-02-11 10:41 ` Matthias Hensler 2006-02-18 14:26 ` Pavel Machek 2006-02-19 21:09 ` Nigel Cunningham 2006-02-19 21:29 ` Pavel Machek 2006-02-20 0:24 ` Nigel Cunningham 2006-02-20 0:53 ` Pavel Machek 2006-02-20 2:50 ` Nigel Cunningham 2006-02-20 12:53 ` Pavel Machek 2006-02-20 9:47 ` Matthias Hensler 2006-02-20 10:56 ` Pavel Machek 2006-02-20 11:04 ` Nigel Cunningham 2006-02-20 13:20 ` Pavel Machek 2006-02-20 11:17 ` Matthias Hensler 2006-02-20 11:20 ` Pavel Machek 2006-02-21 4:32 ` Andy Lutomirski 2006-02-21 4:45 ` Nigel Cunningham 2006-02-21 11:39 ` Pavel Machek 2006-02-21 11:33 ` Pavel Machek 2006-02-21 20:36 ` Rafael J. Wysocki 2006-02-20 9:43 ` Matthias Hensler 2006-02-20 10:36 ` Pavel Machek 2006-02-20 10:50 ` Matthias Hensler 2006-02-20 10:54 ` Pavel Machek 2006-02-20 11:17 ` Matthias Hensler 2006-02-20 13:08 ` Pavel Machek 2006-02-19 23:42 ` suspend2 review [was Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)] Pavel Machek [not found] ` <200602191935.36844.dtor_core@ameritech.net> 2006-02-20 0:44 ` Pavel Machek 2006-02-20 2:10 ` Nigel Cunningham 2006-02-20 12:49 ` Pavel Machek 2006-02-20 17:05 ` Olivier Galibert 2006-02-20 17:10 ` Pavel Machek 2006-02-20 18:31 ` Olivier Galibert 2006-02-20 19:43 ` Pavel Machek 2006-02-21 22:02 ` Lee Revell 2006-02-21 22:17 ` Dmitry Torokhov 2006-02-21 22:21 ` Lee Revell 2006-02-21 23:55 ` Tristan Wibberley 2006-02-20 9:39 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Matthias Hensler 2006-02-20 10:02 ` Lee Revell 2006-02-20 10:10 ` Matthias Hensler 2006-02-20 10:15 ` Lee Revell 2006-02-20 10:24 ` Matthias Hensler 2006-02-20 10:44 ` Nigel Cunningham 2006-02-20 13:37 ` Pavel Machek 2006-02-20 10:37 ` Nigel Cunningham 2006-02-20 13:30 ` Pavel Machek 2006-02-20 14:01 ` Dmitry Torokhov 2006-02-20 14:22 ` Pavel Machek 2006-02-20 20:27 ` Nigel Cunningham 2006-02-20 10:05 ` Sebastian Kügler 2006-02-20 13:01 ` Pavel Machek 2006-02-20 17:01 ` Alon Bar-Lev 2006-02-20 19:12 ` Henrik Brix Andersen 2006-02-20 19:51 ` Theodore Ts'o 2006-02-20 20:08 ` Pavel Machek 2006-02-20 20:36 ` Pavel Machek 2006-02-20 20:44 ` Nigel Cunningham 2006-02-20 20:59 ` Pavel Machek 2006-02-20 21:01 ` Nigel Cunningham 2006-02-20 10:06 ` Lee Revell 2006-02-20 10:15 ` Matthias Hensler 2006-02-20 10:24 ` Lee Revell 2006-02-20 10:33 ` Matthias Hensler 2006-02-20 11:15 ` Lee Revell 2006-02-20 11:24 ` Nigel Cunningham 2006-02-20 13:23 ` Pavel Machek 2006-02-20 14:23 ` Mark Lord 2006-02-20 14:30 ` Pavel Machek 2006-02-20 14:41 ` Dmitry Torokhov 2006-02-20 14:54 ` Pavel Machek 2006-02-20 15:08 ` Dmitry Torokhov 2006-02-20 16:22 ` Rafael J. Wysocki 2006-02-20 16:30 ` Dmitry Torokhov 2006-02-20 17:23 ` Rafael J. Wysocki 2006-02-20 17:33 ` Dmitry Torokhov 2006-02-20 18:19 ` Rafael J. Wysocki 2006-02-20 19:46 ` Lee Revell 2006-02-20 19:45 ` Lee Revell 2006-02-20 20:11 ` Rafael J. Wysocki 2006-02-20 20:15 ` Dmitry Torokhov 2006-02-20 20:30 ` Rafael J. Wysocki 2006-02-20 20:40 ` Lee Revell 2006-02-20 12:24 ` Matthias Hensler 2006-02-20 13:28 ` Pavel Machek 2006-02-20 13:51 ` Matthias Hensler 2006-02-20 14:07 ` Pavel Machek 2006-02-20 14:42 ` Matthias Hensler 2006-02-20 15:01 ` Pavel Machek 2006-02-22 16:15 ` agp fixes in suspend2 patch Thierry Vignaud 2006-02-23 19:04 ` Dave Jones 2006-02-20 14:08 ` Which is simpler? Harald Arnesen 2006-02-20 14:42 ` Pavel Machek 2006-02-20 14:49 ` Matthias Hensler 2006-02-20 14:56 ` Pavel Machek 2006-02-20 10:38 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Nigel Cunningham 2006-02-20 13:30 ` Pavel Machek 2006-02-20 10:11 ` Lee Revell 2006-02-20 10:20 ` Matthias Hensler 2006-02-20 13:03 ` Pavel Machek 2006-02-20 10:40 ` Nigel Cunningham 2006-02-20 12:05 ` Lee Revell 2006-02-20 12:26 ` Matthias Hensler 2006-02-20 12:31 ` Olivier Galibert 2006-02-20 14:13 ` Rafael J. Wysocki 2006-02-20 15:39 ` Olivier Galibert 2006-02-20 16:27 ` Andreas Happe 2006-02-20 17:36 ` Olivier Galibert 2006-02-21 0:52 ` Andreas Happe 2006-02-21 2:57 ` Nigel Cunningham 2006-02-21 4:19 ` Dmitry Torokhov 2006-02-21 5:51 ` Nigel Cunningham 2006-02-21 12:27 ` Pavel Machek 2006-02-21 20:40 ` Rafael J. Wysocki 2006-02-21 21:00 ` Nigel Cunningham 2006-02-21 23:38 ` Rafael J. Wysocki 2006-02-21 23:47 ` Nigel Cunningham 2006-02-22 18:49 ` Rafael J. Wysocki 2006-02-22 22:41 ` Nigel Cunningham 2006-02-22 23:45 ` Rafael J. Wysocki 2006-02-22 22:24 ` Pavel Machek 2006-02-22 23:31 ` Rafael J. Wysocki 2006-02-22 23:56 ` Pavel Machek 2006-02-23 0:11 ` Nigel Cunningham 2006-02-23 0:33 ` Pavel Machek 2006-02-23 0:39 ` Nigel Cunningham 2006-02-23 8:33 ` Rafael J. Wysocki 2006-02-23 8:44 ` Rafael J. Wysocki 2006-02-23 12:17 ` Pavel Machek 2006-02-23 22:37 ` Rafael J. Wysocki 2006-02-23 23:04 ` Pavel Machek 2006-02-23 23:27 ` Nigel Cunningham 2006-02-23 23:44 ` Pavel Machek 2006-02-24 10:58 ` Rafael J. Wysocki 2006-02-24 13:12 ` Pavel Machek 2006-02-24 20:22 ` Rafael J. Wysocki 2006-02-24 23:11 ` Nigel Cunningham 2006-02-24 23:53 ` Pavel Machek 2006-02-25 0:15 ` Pavel Machek 2006-02-25 0:45 ` Rafael J. Wysocki 2006-02-25 0:22 ` Nigel Cunningham 2006-02-25 0:43 ` Pavel Machek 2006-02-25 0:20 ` Rafael J. Wysocki 2006-02-25 0:26 ` Nigel Cunningham 2006-02-25 0:46 ` Pavel Machek 2006-02-25 0:56 ` Rafael J. Wysocki 2006-02-25 5:13 ` Nigel Cunningham 2006-02-24 23:55 ` Pavel Machek 2006-02-26 15:27 ` [RFC/RFT][PATCH -mm] swsusp: improve memory shrinking Rafael J. Wysocki 2006-02-26 18:53 ` Pavel Machek 2006-02-26 23:32 ` Rafael J. Wysocki 2006-02-26 23:38 ` Rafael J. Wysocki 2006-02-26 23:56 ` Pavel Machek 2006-02-27 0:13 ` Rafael J. Wysocki 2006-02-26 23:52 ` Pavel Machek 2006-02-27 0:06 ` Rafael J. Wysocki 2006-02-23 23:16 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Nigel Cunningham 2006-02-21 12:59 ` Which is simpler? (Was " Andreas Happe 2006-02-22 0:33 ` Nigel Cunningham 2006-02-20 16:41 ` Which is simpler? (Was Re: [Suspend2-devel] " Pavel Machek 2006-02-20 17:16 ` Rafael J. Wysocki 2006-02-20 18:16 ` Olivier Galibert 2006-02-20 19:36 ` Pavel Machek 2006-02-20 20:24 ` Rafael J. Wysocki 2006-02-20 12:56 ` Pavel Machek 2006-02-09 13:22 ` Rafael J. Wysocki 2006-02-09 22:16 ` Nigel Cunningham 2006-02-09 23:34 ` Pavel Machek 2006-02-10 0:08 ` Nigel Cunningham 2006-02-10 12:37 ` Rafael J. Wysocki 2006-02-10 23:35 ` Flames over -- " Pavel Machek 2006-02-11 8:53 ` Kyle Moffett 2006-02-11 17:06 ` hackmiester (Hunter Fuller) 2006-02-16 21:32 ` Pavel Machek 2006-02-11 16:36 ` Jan Merka 2006-02-11 22:18 ` Theodoros V. Kalamatianos 2006-02-11 23:35 ` Kyle Moffett 2006-02-12 8:51 ` Alon Bar-Lev 2006-02-12 11:11 ` Kyle Moffett 2006-02-12 12:06 ` Alon Bar-Lev 2006-02-12 16:32 ` Kyle Moffett 2006-02-12 16:56 ` Valdis.Kletnieks 2006-02-12 18:28 ` Kyle Moffett 2006-02-13 12:12 ` Johannes Berg 2006-02-13 12:11 ` Johannes Berg 2006-02-16 21:53 ` Pavel Machek 2006-02-20 6:51 ` Nigel Cunningham 2006-02-12 16:42 ` hackmiester / Hunter Fuller 2006-02-07 23:27 ` Rafael J. Wysocki 2006-02-07 23:50 ` Pavel Machek 2006-02-08 0:16 ` Rafael J. Wysocki 2006-02-08 8:28 ` Pavel Machek 2006-02-08 9:43 ` Rafael J. Wysocki 2006-02-07 23:38 ` Lee Revell 2006-02-07 23:50 ` Jim Crilly 2006-02-07 3:17 ` Lee Revell 2006-02-07 3:32 ` Nigel Cunningham 2006-02-07 4:10 ` Bojan Smojver 2006-02-07 11:01 ` Henrik Brix Andersen 2006-02-07 9:33 ` Pavel Machek 2006-02-07 9:36 ` Nigel Cunningham 2006-02-07 22:57 ` Pavel Machek 2006-02-07 10:17 ` Nigel Cunningham 2006-02-07 15:47 ` Lee Revell 2006-02-07 15:49 ` Pavel Machek 2006-02-06 10:59 ` Pavel Machek 2006-02-06 12:13 ` Nigel Cunningham 2006-02-06 12:40 ` Pavel Machek 2006-02-06 12:50 ` Jens Axboe 2006-02-06 12:52 ` Pavel Machek 2006-02-06 13:04 ` Jens Axboe 2006-02-06 13:45 ` Rafael J. Wysocki 2006-02-06 13:59 ` Jens Axboe 2006-02-06 14:24 ` Pavel Machek 2006-02-06 14:49 ` Mark Lord 2006-02-06 14:52 ` Pavel Machek 2006-02-07 0:20 ` Mark Lord 2006-02-07 0:23 ` Randy.Dunlap [not found] ` <200602100007.10233.rjw@sisk.pl> [not found] ` <20060209231459.GA3389@elf.ucw.cz> [not found] ` <200602100035.04969.rjw@sisk.pl> [not found] ` <20060210002406.GF8154@blackham.com.au> [not found] ` <20060210003533.GJ3389@elf.ucw.cz> 2006-02-11 8:55 ` chroot in swsusp userland interface (was: " Bernard Blackham 2006-02-11 9:50 ` Rafael J. Wysocki 2006-02-03 11:21 ` [ 00/10] [Suspend2] Modules support Pavel Machek 2006-02-04 0:46 ` Barry K. Nathan 2006-02-04 11:02 ` Rafael J. Wysocki 2006-02-11 13:42 ` Eric W. Biederman 2006-02-11 15:19 ` Randy.Dunlap 2006-02-02 10:48 ` Pavel Machek [not found] <5BoER-4GL-3@gated-at.bofh.it> [not found] ` <5DJOW-7ll-9@gated-at.bofh.it> [not found] ` <5DK8h-7YA-13@gated-at.bofh.it> [not found] ` <5DKrG-8nS-13@gated-at.bofh.it> [not found] ` <5DKUI-1Dm-21@gated-at.bofh.it> 2006-02-08 13:23 ` Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.) Bodo Eggert 2006-02-08 14:23 ` Rafael J. Wysocki 2006-02-08 23:20 ` R. J. Wysocki
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).