Re: [PATCH] swsuspend and CONFIG_DISCONTIGMEM=y

William Lee Irwin III (wli@holomorphy.com)
Fri, 15 Nov 2002 01:48:27 -0800


On Fri, Nov 15, 2002 at 12:49:15AM -0800, William Lee Irwin III wrote:
> The following dropped hunk from Pavel should repair it:

[cc: list trimmed to spare the uninterested]

Hmm, there are some oddities here in count_and_copy_data_pages(). It
looks like the CONFIG_HIGHMEM panic() is there because copy_page() is
done without kmapping, and the CONFIG_DISCONTIGMEM panic() is there
because the pgdat list etc. are not walked according to VM conventions.

So the traversal looks like it should go something like:

for_each_zone(zone) {
for (k = 0; k < zone->present_pages; ++k) {
struct page *page = &zone->zone_mem_map[k];

if (!PageReserved) {
if (PageNosave(page))
continue;

chunk_size = is_head_of_free_region(page);

/* c.f. k++ above */
if (chunk_size) {
k += chunk_size - 1;
continue;
}
} else if (PageReserved(page)) {
BUG_ON(PageNosave(page));

if (page_to_pfn(page) >= nosave_begin_pfn
&& page_to_pfn(page) < nosave_end_pfn)
continue;
}

nr_copy_pages++;

/*
* The general usage of page backup entries
* is unclear; this is probably incorrect in
* some cases, and needs some idea of the size
* and layout of the page backup entry array(s)
* if they cannot be contiguously allocated or
* simultaneously mapped by kernel pagetables.
*/
if (pagedir_p) {
char *src, *dst;
src = kmap_atomic(page, KM_SWSUSP0);
dst = kmap_atomic(pagedir_p->page, KM_SWSUSP1);
copy_page(dst, src);
kunmap_atomic(dst, KM_SWSUSP0);
kunmap_atomic(src, KM_SWSUSP1);
++pagedir_p;
}
}
return nr_copy_pages;
}

I don't know what to make of highmem on laptops etc., but the VM's
conventions should not be that hard to follow; also, there are uses for
the swsusp functionality on other kinds of machines (e.g. checkpointing).
Pure computationally-oriented systems such as would make use of this
are somewhat different from my primary userbase to support, but I think
it would be valuable to generalize swsusp in this way, and so provide
rudimentary support for such users in addition to some small measure of
cleanup (i.e. the cleanup adds functionality).

Pavel, what do you think?

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