Re: [PATCH] swsuspend and CONFIG_DISCONTIGMEM=y

[Pavel Machek <pavel@suse.cz>]

Hi!

> > 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.

How much memory is needed for HIGHMEM to be neccessary? Is it 1GB? If
so, I can well imagine 1GB laptop....

> 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;

This certainly does not work. We'd need to do some deep magic in
suspend_asm.S to copy pages back. [Well, deep magic... Same
kmap_atomic.] But suspend_asm.S has to guarantee not touching any
memory so the change is not quite trivial.

> 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?

I definitely want to support swsusp for server boxes, but I'm not 100%
sure how to do that easily.
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.