From: Leroy van Logchem <leroy.vanlogchem@wldelft.nl>
To: linux-kernel@vger.kernel.org
Subject: Re: [RFC][PATCH 0/3] VM throttling: avoid blocking occasional writers
Date: Thu, 1 Mar 2007 12:47:20 +0000 (UTC) [thread overview]
Message-ID: <loom.20070301T133046-12@post.gmane.org> (raw)
In-Reply-To: <45E380DA.6090509@hitachi.com>
Tomoki Sekiyama <tomoki.sekiyama.qu <at> hitachi.com> writes:
> thanks for your comments.
The default dirty_ratio on most 2.6 kernels tend to be too large imo.
If you are going to do sustained writes multiple times the size of
the memory you have at least two problems.
1) The precious dentry and inodecache will be dropped leaving you with
a *very* unresponsive system
2) The amount of dirty_pages which need to be flushed to disk is huge,
taking all VM while the i/o channel takes uninterruptable time to flush it.
What we really need is a 'cfq' for all processes -especially misbehaving
ones like dd if=/dev/zero of=/location/large bs=1M count=10000-.
If you want to DoS the 2.6 kernel, start a ever running dd write and
you know what I mean. Huge latencies due the fact that all name_to_inode
caches are lost and have to be fetched from disk again only to be quickly
flushed again and again. I already explained this disaster scenario with
Linus, Andrew and Jens; hoping for a auto-tuning solution which takes
diskspeed per partition into account.
At the moment we cope with this feature by preserving imported caches with
sysctl vm.vfs_cache_pressure = 1, vm.dirty_ratio = 2 combined with
vm.dirty_background_ratio = 1. Some benchmarks may get worse but you have
a more resiliant server.
I hope the VM subsystem will cope with applications which do not advise
what to do with the cached pages. For now we use posix_fadvice DONT_NEED
as patch to Samba 3 in order to at least be able to write larger then
memory files without discarding the important slab caches.
next prev parent reply other threads:[~2007-03-01 12:50 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-23 12:03 Tomoki Sekiyama
2007-02-24 4:46 ` KAMEZAWA Hiroyuki
2007-02-27 0:50 ` Tomoki Sekiyama
2007-02-27 1:39 ` KAMEZAWA Hiroyuki
2007-03-02 1:26 ` Tomoki Sekiyama
2007-02-24 13:15 ` Nikita Danilov
2007-02-27 0:52 ` Tomoki Sekiyama
2007-03-01 12:47 ` Leroy van Logchem [this message]
2007-03-02 9:16 ` Brice Figureau
2007-03-02 13:06 ` Leroy van Logchem
2007-03-02 16:04 ` Brice Figureau
2007-03-07 13:53 ` Yuji Kakutani
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=loom.20070301T133046-12@post.gmane.org \
--to=leroy.vanlogchem@wldelft.nl \
--cc=linux-kernel@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome