All of lore.kernel.org
 help / color / mirror / Atom feed
From: Iustin Pop <iusty@k1024.org>
To: "Graham, Simon" <Simon.Graham@stratus.com>
Cc: xen-devel@lists.xensource.com
Subject: Re: Reducing impact of save/restore/dump on Dom0
Date: Tue, 6 Feb 2007 19:35:44 +0100	[thread overview]
Message-ID: <20070206183544.GC6768@teal.hq.k1024.org> (raw)
In-Reply-To: <342BAC0A5467384983B586A6B0B3767104A69C19@EXNA.corp.stratus.com>

On Tue, Feb 06, 2007 at 12:46:52PM -0500, Graham, Simon wrote:
> > On linux, there is another way beside O_DIRECT: it's possible to
> > reduce
> > the memory used for cached writing using the sysctl vm.dirty_ratio;
> > I've
> > used this to reduce the impact of heavy cached writes on dom0 with
> > good
> > results.
> > 
> > Maybe it helps for save/dump also...
> 
> Oh interesting -- I shall look into this. 
> 
> I just took a quick peek and it is set to 40% in Dom0; I do see free
> memory go to zero during a dump (and save/restore) plus I see the
> waitIO% go to near 100% and Dom0 becomes somewhat unresponsive;
> specifically what we see is that domain boot fails during this time
> because of a XenBus timeout waiting for the hotplug scripts to finish
> adding the VBD in Dom0.

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

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

Regards,
Iustin

  reply	other threads:[~2007-02-06 18:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-02-06 15:43 Reducing impact of save/restore/dump on Dom0 Graham, Simon
2007-02-06 16:23 ` John Levon
2007-02-06 17:36 ` Iustin Pop
2007-02-06 17:46   ` Graham, Simon
2007-02-06 18:35     ` Iustin Pop [this message]
2007-02-06 23:00 ` Ian Pratt
2007-02-06 23:20   ` Jeremy Fitzhardinge
2007-02-07  6:40     ` Rusty Russell
2007-02-07  7:41       ` Jeremy Fitzhardinge
2007-02-07 12:11 ` Andi Kleen
2007-02-07 12:52   ` Ian Pratt
2007-02-07 12:58     ` Andi Kleen
2007-02-06 17:25 Graham, Simon
2007-02-06 19:21 Graham, Simon
2007-02-07 12:56 Graham, Simon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20070206183544.GC6768@teal.hq.k1024.org \
    --to=iusty@k1024.org \
    --cc=Simon.Graham@stratus.com \
    --cc=xen-devel@lists.xensource.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.