Message-ID: <4A91CBB9.1080702@crca.org.au>
Date:	Mon, 24 Aug 2009 09:07:37 +1000
From:	Nigel Cunningham <ncunningham@...a.org.au>
To:	"Rafael J. Wysocki" <rjw@...k.pl>
CC:	Jiri Slaby <jirislaby@...il.com>,
	linux-pm <linux-pm@...ts.linux-foundation.org>,
	LKML <linux-kernel@...r.kernel.org>,
	TuxOnIce-devel <tuxonice-devel@...ts.tuxonice.net>
Subject: Re: What to do?

Hi.

Rafael J. Wysocki wrote:
> On Sunday 23 August 2009, Jiri Slaby wrote:
>> On 08/20/2009 06:22 AM, Nigel Cunningham wrote:
>>> I'd therefore like to ask whether there's anyone out there who could do
>>> one or more of:
>>>
>>> 1) Step up to the plate and help improve swsusp, without relying on any
>>> help from me but with my blessing if they choose to copy wholesale bits
>>> of TuxOnIce;
>> Hi, I think I can help here.
> 
> Great, thanks!

Yes, thanks for volunteering, Jiri!

We should start by asking where you're at as far as knowledge of swsusp
and TuxOnIce goes. I know you've been around the TuxOnIce lists a bit,
but don't know how much you know about C programming or the inards of
the kernel, swsusp or TuxOnIce (ie how much help do you need to get up
to speed?).

>> Is there any TODO or similar resources?
> 
> Not that I know of, but I think we should start with the non-controversial
> things, like image compression etc.

No, I have a bit of a mental to-do list, but haven't written anything
down yet. Here's a quick, high-level list (some of these things are big):

- Rework swap allocation (as per below) and freeing.
- Rework i/o to use bmapping and lay the foundations for use multiple
block devices.
- Add modular design (will simplify the following additions)
- Add multithreaded I/O
- Add compression support
- Add support for multiple swap devices
- Add support for generic files (file allocator)
- Do storage allocation etc ('image preparation') prior to the atomic
copy instead of afterwards, making the only remaining variable how much
ram drivers' pm routines need (and that might not be an issue by then).
- Add userspace helper support (storage manager/userui).

I'd really like to start with adding the modular design - it will make
things a lot cleaner, but I think we need to do some disentanglement
first (TuxOnIce has all the support for compression in one file that
simply isn't compiled if we don't want compression support. It would be
good to get swsusp set up like that). This is why I have above the
initial thought of handling doing the swap & compression stuff first.

When I prepared those compression patches earlier, it became apparent
that we really need to begin with reworking how the swap is allocated,
remembered and stored in the image header.

The current swsusp scheme of having a page of swap addresses preceding
the pages that are written doesn't work well for compression, because
when rereading the image, you can only do readahead in batches of that
size. Everything will have to grind to a halt while we wait for the next
'index' page.

In TuxOnIce, we allocate all of the swap at the start of preparing to
hibernate, which has other advantages I won't go into now. The pages
allocated are stored as extents in memory. For doing the actual I/O, we
bmap the swap that's allocated right after allocating it, storing the
sector numbers in extents as well (remembering the block sizes that are
relevant as well). We then use them directly in writing the image,
storing major and minor numbers, block sizes and the extents in the
image header for use at resume time.

I'd suggest that the place to begin would be converting swsusp to use
this sort of scheme.

Regarding the non-controversial vs controversial thing, let's not worry
about that. We should do things in the order that's logical, sensible
and lays the foundation for the improvements we're planning to have
follow. If an improvement is really an improvement, it shouldn't be a
big problem to show that it has technical merits that make it
worthwhile. As always in Linux, if someone wants to nak something
without good reason, they'll just end up getting themselves ignored.

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/

Powered by blists - more mailing lists