Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Bodo Eggert]

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.

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[R. J. Wysocki]

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

[ 00/10] [Suspend2] Modules support.

[Nigel Cunningham]

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

Re: [ 00/10] [Suspend2] Modules support.

[Nigel Cunningham]

[-- 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 --]

Re: [ 00/10] [Suspend2] Modules support.

[Pavel Machek]

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!

Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Lee Revell]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Lee Revell]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Bojan Smojver]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Bojan Smojver]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

> > 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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Jim Crilly]

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.

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Jim Crilly]

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.

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Lee Revell]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Jim Crilly]

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.

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Lee Revell]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Sebastian Kügler]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Matthias Hensler]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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         

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Matthias Hensler]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

> 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!

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Matthias Hensler]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Andy Lutomirski]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Matthias Hensler]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Matthias Hensler]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Matthias Hensler]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Matthias Hensler]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Lee Revell]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Matthias Hensler]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Lee Revell]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Matthias Hensler]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

> 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!

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Dmitry Torokhov]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

> 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!

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Sebastian Kügler]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Alon Bar-Lev]

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.

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Henrik Brix Andersen]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Theodore Ts'o]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Lee Revell]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Matthias Hensler]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Lee Revell]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Matthias Hensler]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Lee Revell]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

> 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!

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Mark Lord]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

> 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!

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Dmitry Torokhov]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

> 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!

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Dmitry Torokhov]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Dmitry Torokhov]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Dmitry Torokhov]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Lee Revell]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Lee Revell]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Dmitry Torokhov]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Lee Revell]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Matthias Hensler]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

> 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!

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Matthias Hensler]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

> 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!

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Matthias Hensler]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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!

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

> 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!

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Lee Revell]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Matthias Hensler]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Lee Revell]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Matthias Hensler]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Olivier Galibert]

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.

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Olivier Galibert]

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.

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Andreas Happe]

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/

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Olivier Galibert]

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.

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Andreas Happe]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Dmitry Torokhov]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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
 

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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.

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Olivier Galibert]

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.

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

> > > 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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Lee Revell]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Jim Crilly]

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.

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Lee Revell]

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 

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Bojan Smojver]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Henrik Brix Andersen]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Lee Revell]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Nigel Cunningham]

[-- 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 --]

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Jens Axboe]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Jens Axboe]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Rafael J. Wysocki]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Jens Axboe]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Mark Lord]

 >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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Pavel Machek]

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...

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Mark Lord]

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

Re: Which is simpler? (Was Re: [Suspend2-devel] Re: [ 00/10] [Suspend2] Modules support.)

[Randy.Dunlap]

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