This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-devel] [PATCH 0/5] dump-core take 2:

To: Isaku Yamahata <yamahata@xxxxxxxxxxxxx>
Subject: Re: [Xen-devel] [PATCH 0/5] dump-core take 2:
From: Keir Fraser <keir@xxxxxxxxxxxxx>
Date: Thu, 18 Jan 2007 14:00:38 +0000
Cc: xen-ia64-devel@xxxxxxxxxxxxxxxxxxx, xen-devel@xxxxxxxxxxxxxxxxxxx, Dave Anderson <anderson@xxxxxxxxxx>, John Levon <levon@xxxxxxxxxxxxxxxxx>
Delivery-date: Thu, 18 Jan 2007 06:00:13 -0800
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
In-reply-to: <20070118083302.GD15865%yamahata@xxxxxxxxxxxxx>
List-help: <mailto:xen-devel-request@lists.xensource.com?subject=help>
List-id: Xen developer discussion <xen-devel.lists.xensource.com>
List-post: <mailto:xen-devel@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-devel>, <mailto:xen-devel-request@lists.xensource.com?subject=unsubscribe>
Sender: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx
Thread-index: Acc7CQgZRoVZUab8Edu4iwAX8io7RQ==
Thread-topic: [Xen-devel] [PATCH 0/5] dump-core take 2:
User-agent: Microsoft-Entourage/
On 18/1/07 08:33, "Isaku Yamahata" <yamahata@xxxxxxxxxxxxx> wrote:

> max_pfn isn't sufficient.
> Memory may be sparse on ia64 so that iterating on [0, max_pfn - 1]
> isn't practical. It would take too long time.
> Mempry map is also necessary to avoid dumping I/O regions of a driver domain.

But *you* make up the memory map. Why can't you make it dense for virtual
machines? If you can't, how about pre-defining where the holes are and
implicitly sharing that knowledge between the builder and sav/restore.
They're part of the same toolstack after all.

And if the memory map's extremely sparse that would make saving zero pages
for empty PFNs even more sucky. Or do you avoid that for big holes?

 -- Keir

Xen-devel mailing list