[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:22:07 -0500
  • Delivery-date: Wed, 21 Feb 2007 07:21:27 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdO73yfygbdSnxbR/2AnMRpBcbdNgAy2MewAXo9PloACVlAIAAAS21yAAADr5A=
  • Thread-topic: [Xen-devel] [PATCH][TOOLS] Reducing impact ofdomainsave/restore/dump on Dom0


> 
> Do you need the fsync at all? It's possible that the kernel will
> launder-then-discard the affected pages automatically, just from the
> fadvise() alone.

To be honest, I'm not completely sure; the implementation of the fadvise
call triggers a write back and then explicitely discards any clean pages
-- I don't _think_ it will discard clean pages once the write back
completes (but it's not entirely clear to me how much of the write back
is done synchronously).

However, it definitely makes a perf difference if you explicitely fsync
before each call to fadvise -- therefore I believe that the fadvise call
is definitely not cleaning all the pages inline (which would be
equivalent to the fsync()).

So -- my belief is that without the fsync, there will be some (clean)
pages for the file still in the cache when this is done; my goal was to
remove ALL the pages, but perhaps leaving a few lying around is OK..

/simgr

_______________________________________________
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®.