From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Ian Pratt" Subject: RE: Re: Reducing impact of save/restore/dump on Dom0 Date: Wed, 7 Feb 2007 12:52:58 -0000 Message-ID: <8A87A9A84C201449A0C56B728ACF491E04F480@liverpoolst.ad.cl.cam.ac.uk> References: <342BAC0A5467384983B586A6B0B3767104A69BB9@EXNA.corp.stratus.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Return-path: Content-class: urn:content-classes:message List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Andi Kleen , "Graham, Simon" Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org > > Currently, save, restore and dump all used cached I/O in Dom0 to > > write/read the file containing the memory image of the DomU - when the > > memory assigned to the DomU is greater than free memory in Dom0, this > > leads to severe memory thrashing and generally the Dom0 performance goes > > into the toilet. > > > > The 'classic' answer to avoiding this when writing very large files is, > > of course, to use non-cached I/O to manipulate the files - >=20 > Otherwise you can just use madvise()/fadvise() to tell the kernel > to drop the old data [the later might need a fairly recent kernel > to work] >=20 > It has the advantage that it doesn't need much other changes. It's pretty easy for us to arrange that everything is page aligned. If there was a measurable performance advantage using o_direct rather than madvise/fadvise it probably makes sense to use it -- I can't see o_direct going away any time soon. Ian