public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: William Lee Irwin III <wli@holomorphy.com>
To: pavel@suse.cz
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] swsuspend and CONFIG_DISCONTIGMEM=y
Date: Fri, 15 Nov 2002 01:48:27 -0800	[thread overview]
Message-ID: <20021115094827.GT23425@holomorphy.com> (raw)
In-Reply-To: <20021115084915.GS23425@holomorphy.com>

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

  reply	other threads:[~2002-11-15  9:44 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-15  8:10 [PATCH] swsuspend and CONFIG_DISCONTIGMEM=y Arnaldo Carvalho de Melo
2002-11-15  8:49 ` William Lee Irwin III
2002-11-15  9:48   ` William Lee Irwin III [this message]
2002-11-15 12:02     ` Pavel Machek
2002-11-15 12:09       ` William Lee Irwin III
2002-11-15 18:09         ` Pavel Machek
2002-11-15 18:33           ` William Lee Irwin III
2002-11-15 13:16       ` Benjamin Herrenschmidt
2002-11-15 18:12         ` Pavel Machek
2002-11-15 18:56           ` William Lee Irwin III
2002-11-16  2:41             ` Alan Cox
2002-11-16  3:06               ` William Lee Irwin III
2002-11-16 17:35               ` Oliver Xymoron
2002-11-15 11:54 ` Pavel Machek
2002-11-15 11:57   ` Arnaldo Carvalho de Melo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021115094827.GT23425@holomorphy.com \
    --to=wli@holomorphy.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pavel@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox