Am Dienstag 28 September 2010 schrieb Nigel Cunningham: > Hi Martin. Hi Nigel. > On 29/09/10 05:45, Martin Steigerwald wrote: > > Am Samstag 25 September 2010 schrieb Nigel Cunningham: > >> Hi Rafael. > > > > Hi Nigel, > > > >> Please find attached a slightly updated version of the patchset I > >> sent a few months ago. The main change is that I've prepended and > >> additional patch which lets the user see the speed at which the > >> image is being read and written. This is accomplished by recording > >> the MB/s in a single byte in the image header, and using a couple > >> of __nosavedata variables to get the data back through the atomic > >> restore. I realise the char limits us to 255MB/s at the moment. In > >> future patches, I intend to address this by storing the data in a > >> 'proper' image header (it's a real problem - TuxOnIce reads and > >> writes on the same set up at speeds around 250MB/s). > > > >> Results on my Dell XPS M1530, which has an SSD hard drive are: > > I found one issue with this patchset or more precise I think with the > > state of in-kernel-suspend before: > > > > I accidentally booted a kernel without your patches and it didn't > > seem to stop on the hibernation image from the kernel with your > > patches. Well I let my laptop unattended for a little while, so when > > there has been a (short) timeout, I might have missed that message. > > > > I lost a hibernation image this way which caused successful journal > > replay on my Ext4 filesystems. > > > > Does a kernel without your patches offer to reboot into the correct > > kernel, then it finds a hibernation image from a kernel with your > > patches? > > > > If not, I think for the future it should give a warning with a quite > > high timeout, and offer to reboot into the right kernel. > > My patches only focus on the I/O code in swsusp at the moment. I know > there are still tons of things from TuxOnIce that could be put into > swsusp, but at the moment I'm just focusing on I/O code. > > The answer at the moment is therefore "I'm sorry, but if you're going > to try out this code, you're going to have to live without some of > TuxOnIce's nice features until I can split them into nice little > patches, and start trying to persuade Rafael they're a good idea to > merge." > > Sorry! No problem. I wasn't aware that in kernel suspend does not have any checks like that, cause TuxOnIce and Userspace Software Suspend both have them. Thus I thought, that the check somehow did not trigger while it should. But if no check was in there, this is no problem with your patches. I try to avoid booting from kernels without your patches when I suspend from one with your patches by making sure that the kernel with your patches is the first in grub menu ;). I think a check should go in as soon as possible tough. Cause anything else just asks for filesystem corruption. I still have a "sync" in my pre hibernate script that calls the hibernate script. And Ext4 is good at recovering from journals. But still... Ciao, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ linux-pm mailing list linux-pm@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/linux-pm
