From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Graham, Simon" Subject: RE: Reducing impact of save/restore/dump on Dom0 Date: Wed, 7 Feb 2007 07:56:57 -0500 Message-ID: <342BAC0A5467384983B586A6B0B3767104A69CF8@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: Jeremy Fitzhardinge , Ian Pratt Cc: xen-devel@lists.xensource.com List-Id: xen-devel@lists.xenproject.org > -----Original Message----- > From: Jeremy Fitzhardinge [mailto:jeremy@goop.org] > Ian Pratt wrote: > > 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. > O_DIRECT is strongly deprecated. fadvise(..., FADV_DONTNEED, ...) is > the preferred interface. I'm currently experimenting with using fsync/fadvise - will post results shortly. If this works well, then it's not essential to change the on-disk format although I think the performance will be better if it is changed. I do find it a little annoying that in Linux the routine is actually called posix_fadvise64 rather than fadvise64 but I can obviously work round that. Simon