All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Kara <jack@suse.cz>
To: lsf10-pc@lists.linuxfoundation.org
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org
Subject: [LSF/VM TOPIC] Dynamic sizing of dirty_limit
Date: Wed, 24 Feb 2010 15:34:42 +0100	[thread overview]
Message-ID: <20100224143442.GF3687@quack.suse.cz> (raw)

  Hi,

  one more suggestion for discussion:
Currently, the amount of dirtiable memory is fixed - either to a percentage
of ram (dirty_limit) or to a fix number of megabytes. The problem with this
is that if you have application doing random writes on a file (like some
simple databases do), you'll get a big performance improvement if you
increase the amount of dirtiable memory (because you safe quite some
rewrites and also get larger chunks of sequential IO) (*)
On the other hand for sequential IO increasing dirtiable memory (beyond
certain level) does not really help - you end up doing the same IO.  So for
a machine is doing sequential IO, having 10% of memory dirtiable is just
fine (and you probably don't want much more because the memory is better
used for something else), when a machine does random rewrites, going to 40%
might be well worth it. So I'd like to discuss how we could measure that
increasing amount of dirtiable memory helps so that we could implement
dynamic sizing of it.

(*) We ended up increasing dirty_limit in SLES 11 to 40% as it used to be
with old kernels because customers running e.g. LDAP (using BerkelyDB
heavily) were complaining about performance problems.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

WARNING: multiple messages have this Message-ID (diff)
From: Jan Kara <jack@suse.cz>
To: lsf10-pc@lists.linuxfoundation.org
Cc: linux-fsdevel@vger.kernel.org, linux-mm@kvack.org
Subject: [LSF/VM TOPIC] Dynamic sizing of dirty_limit
Date: Wed, 24 Feb 2010 15:34:42 +0100	[thread overview]
Message-ID: <20100224143442.GF3687@quack.suse.cz> (raw)

  Hi,

  one more suggestion for discussion:
Currently, the amount of dirtiable memory is fixed - either to a percentage
of ram (dirty_limit) or to a fix number of megabytes. The problem with this
is that if you have application doing random writes on a file (like some
simple databases do), you'll get a big performance improvement if you
increase the amount of dirtiable memory (because you safe quite some
rewrites and also get larger chunks of sequential IO) (*)
On the other hand for sequential IO increasing dirtiable memory (beyond
certain level) does not really help - you end up doing the same IO.  So for
a machine is doing sequential IO, having 10% of memory dirtiable is just
fine (and you probably don't want much more because the memory is better
used for something else), when a machine does random rewrites, going to 40%
might be well worth it. So I'd like to discuss how we could measure that
increasing amount of dirtiable memory helps so that we could implement
dynamic sizing of it.

(*) We ended up increasing dirty_limit in SLES 11 to 40% as it used to be
with old kernels because customers running e.g. LDAP (using BerkelyDB
heavily) were complaining about performance problems.

								Honza
-- 
Jan Kara <jack@suse.cz>
SUSE Labs, CR

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

             reply	other threads:[~2010-02-24 14:34 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-02-24 14:34 Jan Kara [this message]
2010-02-24 14:34 ` [LSF/VM TOPIC] Dynamic sizing of dirty_limit Jan Kara
2010-02-24 16:10 ` Christoph Lameter
2010-02-24 23:30   ` Andreas Dilger
2010-02-24 23:30     ` Andreas Dilger
2010-03-08  7:33   ` Boaz Harrosh
2010-03-08  7:33     ` Boaz Harrosh

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=20100224143442.GF3687@quack.suse.cz \
    --to=jack@suse.cz \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lsf10-pc@lists.linuxfoundation.org \
    /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.