Xen devel - Feb 2007 - RE: [PATCH][TOOLS] Reducing impact of domainsave/restore/dump on Dom0

Take 2... this version only adds code to discard the cache on Linux and
uses the right name for the fadvise call.

It''s a bit ugly - I basically just put #ifdef __linux__ around the
fadvise calls - but I don''t have the ability to develop something
suitable for Solaris...
> Attached is a patch to unstable that stops save/restore/dump from
> hosing
> Dom0 when dealing with large domains - I''m actually resubmitting
the
> dump patch I previously submitted in addition as it hasn''t been
> incorporated yet; this is based on using fadvise64(DONTNEED) to throw
> the page cache away once it has been written to disk -- with this in
> place, memory usage does go up somewhat but then immediately drops
> again
> when the action is done and this change, in conjunction with setting
> the
> vm.dirty_ratio sysctl parameter seems to gives very good results.
> 
Simon

-----------------------------------
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@stratus.com>


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

On 13/2/07 22:12, "Graham, Simon" <Simon.Graham@stratus.com>
wrote:
> 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@stratus.com>
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)?

 -- Keir


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