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

RE: [Xen-devel] Reducing impact of save/restore/dump on Dom0

  • To: "Iustin Pop" <iusty@xxxxxxxxx>
  • From: "Graham, Simon" <Simon.Graham@xxxxxxxxxxx>
  • Date: Tue, 6 Feb 2007 14:21:57 -0500
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
  • Delivery-date: Tue, 06 Feb 2007 11:21:32 -0800
  • List-id: Xen developer discussion <xen-devel.lists.xensource.com>
  • Thread-index: AcdKHaGJ5qUbUvaIRoGiq9CB+rDQsgABdi6g
  • Thread-topic: [Xen-devel] Reducing impact of save/restore/dump on Dom0

> Yes, that's more or less expected. I've used 10% (you can't go below
> = harcoded limit in the kernel) and then, for a 512MB dom0, only ~25
> of cache will be used. I would hardly say that 25MB is too much.

Well, I think it means only 25MB of dirty cache is allowed before writes
become synchronous - you will still use all of memory for the cache, it
will just be cleaned earlier and therefore available for reuse plus the
penalty for the write moves to the writer rather than to everyone
else... Still, I agree it's worth experimenting with (and I intend to).

> > I still feel that dump/save/restore files really don't belong in the
> > system cache at all since they just pollute the cache for no ggood
> > reason.
> Then there is also posix_fadvise, which is more or less what you need
> to
> use in case you worry about your cache. I haven't used it, but I've
> heard from people that using fadvise with POSIX_FADV_DONTNEED+fsync or
> O_SYNC in batches can reduce your cache usage.
> Just a few thoughts, as these don't change the way you do writes, as
> opposed to O_DIRECT.

I certainly would prefer this too; I hadn't considered using
POSIX_FADV_DONTNEED/fsync in the loop...

Thanks for the suggestions,

Xen-devel mailing list



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