[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [Xen-devel] Reducing impact of save/restore/dump on Dom0

  • To: "Graham, Simon" <Simon.Graham@xxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Ian Pratt" <m+Ian.Pratt@xxxxxxxxxxxx>
  • Date: Tue, 6 Feb 2007 23:00:17 -0000
  • Delivery-date: Tue, 06 Feb 2007 15:00:26 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdKBZPMvfN8lviOSuqtXI34KOqxhwAO8z6Q
  • Thread-topic: [Xen-devel] Reducing impact of save/restore/dump on Dom0

> Solving this problem for save/restore is more tricky because the
> on-disk/wire save format does not force the page data to be page
> -- my proposal would be to page align each batch of pages written,
> leaving pad between the batch header and the pages themselves but I
> realize that a change in on-disk/wire format is a potential
> compatibility problem.

The on-disk format is due to change before 3.0.5 anyhow. Page aligning
the data pages is certainly something I'd like to see happen. The
easiest way of doing this is to add some padding to align things at the
start of the page write-out loop, then in the PV case, make sure that
the page-type batches are padded to page size. (I'd reduce the max batch
size slightly so that in the normal case the batch fits nicely in 1
page, or 2 for 64b).

As for making the IO bypass the buffer cache, I'm not sure what the best
way to do this is. There are some occasions where we want the restore
image to be in the buffer cache (e.g. as used by the fault injection
testing for fast domain restart) but I agree that its not helpful in the
normal case. My first inclination would be O_DIRECT, but there may be a
better way.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.