: 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: Bojan Smojver on 30 Jul 2010 06:50 On Fri, 2010-07-30 at 14:46 +1000, Bojan Smojver wrote: > This patch speeds up hibernate/thaw operations This is probably a bit simpler. -- Bojan
From: Nigel Cunningham on 30 Jul 2010 18:10 Hi Bojan. On 30/07/10 20:44, Bojan Smojver wrote: > On Fri, 2010-07-30 at 14:46 +1000, Bojan Smojver wrote: >> This patch speeds up hibernate/thaw operations > > This is probably a bit simpler. In general, it looks good. Is an order 6 allocation really necessary, though? I guess they'll be more reliably achieved with swsusp freeing so much memory beforehand but still... Regards, 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 30 Jul 2010 18:30 On Sat, 2010-07-31 at 08:05 +1000, Nigel Cunningham wrote: > In general, it looks good. Is an order 6 allocation really necessary, > though? To be honest, I don't really know. I kinda guessed that the more data compress routine has, the more it's going to be able to squeeze it down. I can do some tests with 5 or even 4. Will let you know. -- 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 30 Jul 2010 19:30 On Sat, 2010-07-31 at 08:05 +1000, Nigel Cunningham wrote: > Is an order 6 allocation really necessary, > though? I tried with 5 and 4 and got slightly lower throughput numbers. With 6, I was getting 145 to 150 MB/s, with 4 I'm getting around 130 MB/s (this is all on hibernate). So, here is one with 4. PS. I guess with this, read_sync can simply disappear as well. -- Bojan
From: Nigel Cunningham on 30 Jul 2010 19:50
Hi again. On 31/07/10 09:22, Bojan Smojver wrote: > On Sat, 2010-07-31 at 08:05 +1000, Nigel Cunningham wrote: >> Is an order 6 allocation really necessary, >> though? > > I tried with 5 and 4 and got slightly lower throughput numbers. With 6, > I was getting 145 to 150 MB/s, with 4 I'm getting around 130 MB/s (this > is all on hibernate). > > So, here is one with 4. How about vmallocing the cmp as well? That would greatly reduce the potential for page allocation failures while still letting you use an order 6 area. I might try this for TuxOnIce too - I'm only using order 0 allocations at the moment and have been wondering how I can get the higher write speed I think should be possible on my system :) I was thinking along the lines of locking, but perhaps that was the wrong area to pursue! :) > PS. I guess with this, read_sync can simply disappear as well. I haven't looked at the code for a while, but it might still be needed for the header? I know that in TuxOnIce, I need to read the first page synchronously when bootstrapping reading the image (can't read the next page until you know where it is, and its location is on the first page). Since swsusp uses those index pages, I think it would have the same issue - they would need to be read before it could read the following pages. Of course I'm going off memory :) 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/ |