: Compress hibernation image with LZO (in-kernel)
in [Kernel]
|
Prev: powerpc: Use IRQF_NO_SUSPEND not IRQF_TIMER for non-timer interrupts
Next: [PATCH 3/9] staging: otus: check kmalloc() return value
From: Nigel Cunningham on 4 Aug 2010 00:30 Hi. On 04/08/10 14:04, Bojan Smojver wrote: > On Wed, 2010-08-04 at 12:47 +1000, Bojan Smojver wrote: >> Points taken for all the other comments. Thank you. > > Style wise, does this look better? > > PS. Don't worry about contents yet - still working out the kinks. Okay. > diff --git a/kernel/power/Kconfig b/kernel/power/Kconfig > index ca6066a..cb57eb9 100644 > --- a/kernel/power/Kconfig > +++ b/kernel/power/Kconfig > @@ -137,6 +137,8 @@ config SUSPEND_FREEZER > config HIBERNATION > bool "Hibernation (aka 'suspend to disk')" > depends on PM&& SWAP&& ARCH_HIBERNATION_POSSIBLE > + select LZO_COMPRESS > + select LZO_DECOMPRESS But, having said 'okay' above, I should point out that you might want to select CRYPTO too, since LZO depends on it. (And perhaps I should ask whether you should be using cryptoapi rather than LZO directly?) > select SUSPEND_NVS if HAS_IOMEM > ---help--- > Enable the suspend to disk (STD) functionality, which is usually > diff --git a/kernel/power/swap.c b/kernel/power/swap.c > index b0bb217..1515e2c 100644 > --- a/kernel/power/swap.c > +++ b/kernel/power/swap.c > @@ -24,6 +24,7 @@ > #include<linux/swapops.h> > #include<linux/pm.h> > #include<linux/slab.h> > +#include<linux/lzo.h> > > #include "power.h" > > @@ -357,6 +358,30 @@ static int swap_writer_finish(struct swap_map_handle *handle, > return error; > } > > +/* We need to remember how much compressed data we need to read. */ > +#define LZO_HEADER sizeof(size_t) > + > +/* Number of pages/bytes we'll compress at a time. */ > +#define LZO_UNC_PAGES 64 > +#define LZO_UNC_SIZE (LZO_UNC_PAGES * PAGE_SIZE) > + > +/* Number of pages/bytes we need for compressed data (worst case). */ > +#define LZO_CMP_PAGES DIV_ROUND_UP(lzo1x_worst_compress(LZO_UNC_SIZE) + \ > + LZO_HEADER, PAGE_SIZE) > +#define LZO_CMP_SIZE (LZO_CMP_PAGES * PAGE_SIZE) > + > +/* As per examples/overlap.c in lzo distribution, we need to add more space > + * to the end of the buffer in order to perform overlapping compression. We > + * also add LZO_HEADER, because our compressed data starts at that offset. > + * Then we round it off on PAGE_SIZE boundary, so that we can copy full pages > + * safely. We call this overhead. Magic numbers and formula below. > + */ Yeah, that's much better; thanks. Nigel -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Bojan Smojver on 4 Aug 2010 01:20 > But, having said 'okay' above, I should point out that you might want to > select CRYPTO too, since LZO depends on it. (And perhaps I should ask > whether you should be using cryptoapi rather than LZO directly?) OK, I will check. I kinda remember the docs just saying to select the above. I looked at crypto briefly, but then decided to use straight compression because it looked a straightforward match for the task at hand. -- Bojan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Bojan Smojver on 4 Aug 2010 02:00 On Wed, 2010-08-04 at 15:12 +1000, Bojan Smojver wrote: > OK, I will check. I kinda remember the docs just saying to select the > above. Looks to me the dependencies go the other way around (i.e. crypto depends on LZO, not LZO on crypto): ----------------- config CRYPTO_LZO tristate "LZO compression algorithm" select CRYPTO_ALGAPI select LZO_COMPRESS select LZO_DECOMPRESS help This is the LZO algorithm. ----------------- So, one needs LZO_COMPRESS/DECOMPRESS for CYPTO_LZO. But, given we just need straight compression/decompression, this should not be needed, if I'm understanding things correctly. -- Bojan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Bojan Smojver on 4 Aug 2010 21:30 On Wed, 2010-08-04 at 12:47 +1000, Bojan Smojver wrote: > PS. Right now, I'm seeing segfaults on resume with my > overlapping/in-place approach. So, I'll have to find out what is going > on first. Well, either I'm doing something idiotic when setting up overlapping/in-place compression/decompression buffers or the routines do not work as advertised. In any event, the image is subtly corrupt on resume using this technique (checksum verified), hence the segfaults. Please do not use this code on your systems - it may corrupt your file systems. For now, I will finalize the patch using two buffers, but I'll drop the number of pages down to 32, so that we use roughly the same amount of memory as with overlapping/in-place compression/decompression. Slightly slower than with 64 pages, but still much faster than original code. -- Bojan -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Pavel Machek on 5 Aug 2010 02:30
Hi! > This patch speeds up hibernate/thaw operations (in kernel ones) by > compressing the pages using LZO. Tests on my ThinkPad T510 show that > hibernation times can be cut by the factor of about 4 for an image of > around 1 GB (from about a minute down to about 15 seconds). Why do it in kernel? s2disk should already be faster... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |