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

RE: [Xen-devel] [PATCH][TOOLS] Reducing impact ofdomainsave/restore/dump on Dom0


  • To: "Keir Fraser" <keir@xxxxxxxxxxxxx>, <xen-devel@xxxxxxxxxxxxxxxxxxx>
  • From: "Graham, Simon" <Simon.Graham@xxxxxxxxxxx>
  • Date: Wed, 21 Feb 2007 10:06:56 -0500
  • Delivery-date: Wed, 21 Feb 2007 07:06:27 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdO73yfygbdSnxbR/2AnMRpBcbdNgAy2MewAXo9PloACVlAIA==
  • Thread-topic: [Xen-devel] [PATCH][TOOLS] Reducing impact ofdomainsave/restore/dump on Dom0

> > Reduce impact of saving/restoring/dumping large domains on Dom0
> memory
> > usage by means of fadvise64() to tell the OS to discard the cache
> pages
> > used for the save/dump file.
> >
> > Signed-off-by: Simon Graham <Simon.Graham@xxxxxxxxxxx>
> 
> Could the fadvise() logic be shared more than it is in this patch?
Also
> you
> sometimes sync-then-fadvise. Is this just a performance enhancement
> (presumably fadvise wouldn't simply discard dirty pages in the buffer
> cache)?
> 

1. You mean putting the fsync/fadvise in a common utility routine? I can
do that.

2. sync-then-advise is only done at the end of writing a file to ensure
that all
   of the cached pages are discarded. Whilst writing the file, I only
fadvise
   which triggers a write back and discards any clean pages up to the
specified offset.
   This is indeed a performance thing -- fsyncing on every write makes
it very slow.

Updated patch will follow...


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel


 


Rackspace

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