|
|
|
|
|
|
|
|
|
|
xen-devel
Re: [Xen-devel] [PATCH 0/5] dump-core take 2:
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
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
<Prev in Thread] |
Current Thread |
[Next in Thread> |
- [Xen-devel] [PATCH 3/5] dump-core take 2: libxc: add xc_domain_tranlate_gpfn(), (continued)
- Re: [Xen-devel] [PATCH 0/5] dump-core take 2:,
Keir Fraser <=
|
|
|
|
|