linux-toradex.git/kernel/power/swap.c, branch v2.6.20.17

[PATCH] swsusp: Do not fail if resume device is not set

2007-01-06T07:55:22+00:00

In the kernels later than 2.6.19 there is a regression that makes swsusp
fail if the resume device is not explicitly specified.

It can be fixed by adding an additional parameter to
mm/swapfile.c:swap_type_of() allowing us to pass the (struct block_device
*) corresponding to the first available swap back to the caller.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Pavel Machek 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] swsusp: Fix labels

2006-12-07T16:39:28+00:00

Move all labels in the swsusp code to the second column, so that they won't
fool diff -p.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Pavel Machek 
Cc: Nigel Cunningham 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] swsusp: Measure memory shrinking time

2006-12-07T16:39:28+00:00

Make swsusp measure and print the time needed to shrink memory during the
suspend.

Signed-off-by: Rafael J. Wysocki 
Cc: Pavel Machek 
Cc: Nigel Cunningham 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] swsusp: use __GFP_WAIT

2006-12-07T16:39:27+00:00

swsusp uses GFP_ATOMIC, but it can afford to use __GFP_WAIT, which will
permit it to reclaim clean pagecache instead of emitting scary
page-allocation-failure messages.

Cc: Pavel Machek 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] swsusp: Improve handling of highmem

2006-12-07T16:39:27+00:00

Currently swsusp saves the contents of highmem pages by copying them to the
normal zone which is quite inefficient (eg.  it requires two normal pages
to be used for saving one highmem page).  This may be improved by using
highmem for saving the contents of saveable highmem pages.

Namely, during the suspend phase of the suspend-resume cycle we try to
allocate as many free highmem pages as there are saveable highmem pages.
If there are not enough highmem image pages to store the contents of all of
the saveable highmem pages, some of them will be stored in the "normal"
memory.  Next, we allocate as many free "normal" pages as needed to store
the (remaining) image data.  We use a memory bitmap to mark the allocated
free pages (ie.  highmem as well as "normal" image pages).

Now, we use another memory bitmap to mark all of the saveable pages
(highmem as well as "normal") and the contents of the saveable pages are
copied into the image pages.  Then, the second bitmap is used to save the
pfns corresponding to the saveable pages and the first one is used to save
their data.

During the resume phase the pfns of the pages that were saveable during the
suspend are loaded from the image and used to mark the "unsafe" page
frames.  Next, we try to allocate as many free highmem page frames as to
load all of the image data that had been in the highmem before the suspend
and we allocate so many free "normal" page frames that the total number of
allocated free pages (highmem and "normal") is equal to the size of the
image.  While doing this we have to make sure that there will be some extra
free "normal" and "safe" page frames for two lists of PBEs constructed
later.

Now, the image data are loaded, if possible, into their "original" page
frames.  The image data that cannot be written into their "original" page
frames are loaded into "safe" page frames and their "original" kernel
virtual addresses, as well as the addresses of the "safe" pages containing
their copies, are stored in one of two lists of PBEs.

One list of PBEs is for the copies of "normal" suspend pages (ie.  "normal"
pages that were saveable during the suspend) and it is used in the same way
as previously (ie.  by the architecture-dependent parts of swsusp).  The
other list of PBEs is for the copies of highmem suspend pages.  The pages
in this list are restored (in a reversible way) right before the
arch-dependent code is called.

Signed-off-by: Rafael J. Wysocki 
Cc: Pavel Machek 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] swsusp: add resume_offset command line parameter

2006-12-07T16:39:27+00:00

Add the kernel command line parameter "resume_offset=" allowing us to specify
the offset, in  units, from the beginning of the partition pointed
to by the "resume=" parameter at which the swap header is located.

This offset can be determined, for example, by an application using the FIBMAP
ioctl to obtain the swap header's block number for given file.

[akpm@osdl.org: we don't know what type sector_t is]
Signed-off-by: Rafael J. Wysocki 
Cc: Pavel Machek 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] swsusp: use block device offsets to identify swap locations

2006-12-07T16:39:27+00:00

Make swsusp use block device offsets instead of swap offsets to identify swap
locations and make it use the same code paths for writing as well as for
reading data.

This allows us to use the same code for handling swap files and swap
partitions and to simplify the code, eg.  by dropping rw_swap_page_sync().

Signed-off-by: Rafael J. Wysocki 
Cc: Pavel Machek 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] swsusp: rearrange swap-handling code

2006-12-07T16:39:27+00:00

Rearrange the code in kernel/power/swap.c so that the next patch is more
readable.

[This patch only moves the existing code.]

Signed-off-by: Rafael J. Wysocki 
Acked-by: Pavel Machek 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] swsusp: use partition device and offset to identify swap areas

2006-12-07T16:39:27+00:00

The Linux kernel handles swap files almost in the same way as it handles swap
partitions and there are only two differences between these two types of swap
areas:

(1) swap files need not be contiguous,

(2) the header of a swap file is not in the first block of the partition
    that holds it.  From the swsusp's point of view (1) is not a problem,
    because it is already taken care of by the swap-handling code, but (2) has
    to be taken into consideration.

In principle the location of a swap file's header may be determined with the
help of appropriate filesystem driver.  Unfortunately, however, it requires
the filesystem holding the swap file to be mounted, and if this filesystem is
journaled, it cannot be mounted during a resume from disk.  For this reason we
need some other means by which swap areas can be identified.

For example, to identify a swap area we can use the partition that holds the
area and the offset from the beginning of this partition at which the swap
header is located.

The following patch allows swsusp to identify swap areas this way.  It changes
swap_type_of() so that it takes an additional argument representing an offset
of the swap header within the partition represented by its first argument.

Signed-off-by: Rafael J. Wysocki 
Acked-by: Pavel Machek 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds

[PATCH] swsusp: fix memory leaks

2006-10-17T15:18:44+00:00

My fancy new swsusp IO code had a big memory leak.  It's somewhat invisible
because the whole mem_map[] gets overwritten after resume, but it can cause us
to get low on memory during the actual suspend process.

Cc: "Rafael J. Wysocki" 
Cc: Pavel Machek 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds