linux-kernel - Re: [PATCH 13/23] Hibernation: Partial page I/O support.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <4CB621DF.9070109@tuxonice.net>
Date:	Thu, 14 Oct 2010 08:17:19 +1100
From:	Nigel Cunningham <nigel@...onice.net>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
CC:	Pavel Machek <pavel@....cz>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	TuxOnIce-devel <tuxonice-devel@...onice.net>
Subject: Re: [PATCH 13/23] Hibernation: Partial page I/O support.

Hi.

On 14/10/10 07:28, Rafael J. Wysocki wrote:
> On Wednesday, October 13, 2010, Pavel Machek wrote:
>> Hi!
>>
>>> Add functions that can be used for coalescing and splitting buffers
>>> that are smaller than PAGE_SIZE. These functions provide no method
>>> of determining where the boundaries of the smaller buffers are to
>>> be found - that is the caller's problem.
>>
>> I don't get it; why do we need that support?
>
> This is related to compression.  This way we can put data from two or more
> compressed pages into one page frame.

It also provides a simple way of putting information from multiple 
sources into a larger-than-at-the-moment header:

- Which pfns are stored
- What swap extents are used
- What devices are used (dev_t, UUID, last mount time for each)
- Whether compression is enabled and what algo is used (if made 
configurable)

and so on.

I do see the logic to Pavel's question though - the last set of patches 
I sent didn't switch the compression code over to using this support. 
That change would make their usefulness a lot clearer.

Regarding speed, I haven't measured the difference but would expect that 
the cost of combining and splitting pages in this way would be less than 
that of waiting on extra I/O. In addition, if we merge the pages in this 
way, our image size will be much closer to the compression ratio and 
will therefore make it more feasible for us to estimate how much storage 
is needed, taking into account an expected compression ratio (which is 
what TuxOnIce currently does).

Regards,

Nigel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/